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A prototype production rule program, DECAIDS, for the 
support of decisions on computer resources was constructed 
using the Stanford University EMYCIN production rule system. 
The DECAIDS program demonstrates the use of a production rule 
system to support a relatively unstructured management 
problem. A discussion of knowledge based systems, predicate 
calculus and production rules is included. A tutorial 
section discusses the user information needed for development 
of a backward -chaining , goal -seeking knowledge base system. 
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I. INTRODUCTION 



Production rule systems provide a means for encoding 
"expert” knowledge about some domain of information and offer 
techniques for using this knowledge to provide answers for 
questions in the domain. A prototype production rule program, 
DECAIDS (Decision aids) , was developed using current 
Artificial Intelligence (AI) methodology in an effort to 
organize decision aiding characteristics relating to computer 
resource allocation alternatives. The purpose of this 
program is to provide recommendations during an interactive 
consultation session. During this session, specific informa- 
tion is requested from the consultation system user concerning 
his organization's task, technology, environment, and struc- 
ture characteristics. This information is then used to 
invoke system production rules which are used to produce 
the recommendations . 

While the primary subjects of this paper are the pro- 
duction rule system and a sample categorization of managerial 
decision aids, it is noteworthy to mention that several other 
areas of study are involved. These include inferential 
analysis, organizational theory, predicate calculus, and 
decision aid characteristics. The last section in this 
thesis is a tutorial containing instructions for the use of 
the EMYCIN inference engine and procedures for designing 
and implementing a database (referred to as a knowledge base) . 
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While some AI systems do attempt to model the human 
thought process, this paper has adopted the EMYCIN inference 
engine developed from Stanford University's MYCIN research 
program. This program, EMYCIN, permits problems to be 
solved using goal -directed , backward -chaining production 
rules. Backward-chaining is a tree traversal method. It 
is accomplished by searching through a tree from a goal, 
bottom leaf, state toward some initial, root node, state. 

The concept of "spaces" may also be used here to further 
explain that the shape of the state space determines whether 
forward or backward -chaining is utilized; fanning in from 
some goal state to an initial state represents backward- 
chaining [Winston, 1977] . 

The important thing in AI is that a software program 
produces "behavior" similar to that which a human can produce, 
understand, and recognize. Generally, the problems posed to 
AI are not those for which a specific algorithm can be 
written. For instance, a manager probably could not explain, 
algorithmically, how he arrived at a particular decision. 

He uses a myriad of facts, procedures, and experiences to 
tell him what to do during certain circumstances and these 
factors are used to produce a decision. EMYCIN was developed 
with the assumption that a human would use the same data that 
the program used but not in the same manner. The program 
provides a method to weigh conflicting information, calcu- 
lating how much information is sufficient to achieve a 
recommendation, and identifying those cases where insufficient 
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information is available to arrive at an acceptable decision. 
This is what a human does when making a decision. The AI 
program must therefore parallel these human processes as 
closely as possible in order to produce an acceptable 
result [Scott, 1979]. 

The EMYCIN program is written in INTERLISP. This computer 
language provides an excellent basis for an AI system since 
the information in the knowledge base is grouped into lists, 
at the tree nodes, and these lists are appropriately manipu- 
lated by INTERLISP functions. This thesis provides the 
background materials and concepts required to design, 
implement, and operate an Artificial Intelligence knowledge 
based system. 
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II. BACKGROUND 



The first domain in which computers have successfully 
demonstrated expert performance is mathematical problem 
solving. The speed with which computers can solve arith- 
metic problems is well known. The ability of the user to 
adequately prepare the program for a particular problem is 
the major limiting factor in computer performance. Pro- 
duction rule systems will be discussed as a method of 
preparation, or representation, of data used in Artificial 
Intelligence programs . 

Artificial Intelligence (AI) is a relatively unexplored 
area of computer science. Simply stated, AI is the study 
of ideas which enable a computer to perform in a manner 
that resembles intelligent behavior. The ability to acquire 
and apply knowledge, to manipulate and communicate ideas, 
and the ability to reason are all parts of this intelligent 
behavior. A concise definition of intelligence is diffi- 
cult to state because of the wide range of information- 
processing and information-representation concepts involved. 
The primary goals of AI are to make computers more useful 
and to comprehend the principles which make intelligence 
possible [Winston, 1977, p. 1]. 

A. ARTIFICIAL INTELLIGENCE SYSTEMS 

The field of Artificial Intelligence is concerned with 
producing systems which operate in five basic areas. These 
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represent basic human activities and therefore the supporting 
systems are referred to as Artificial Intelligence [Nilson, 
1978, p. 1-13]. The first of these areas is intelligent 
information retrieval. 

Information retrieval, from database systems, is not a 
new problem to computer science. However, when the asso- 
ciated system is designed to produce inferences or deductions 
dependent upon the information in the database, the program 
takes on apparent intelligence. Use of natural language 
(i.e., English) methods to produce deductions and storage 
of large amounts of generally known information are the 
primary design considerations facing the system designer. 

Expert information, in the form of rules, inference 
statements, is interpreted to produce values for parameters, 
which are the program's ultimate output. The domain of 
computer resource allocation based upon organizational 
structure is an example of an intelligent information 
retrieval system contained in this paper. Theorem proving, 
disease diagnosis, mechanical controls (robots), and auto- 
mated programming are some other applications for AI 
[Nilsson, 1971]. 

One of the problems encountered in AI is the requirement 
for categorizing into a manageable form vast amounts of data. 

A system may be provided with sensory equipment which collects 
input data. However, unless there is sufficient information 
for the system, for example a robot, to test against, the 
interpretation of the input data may be incomplete. 
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The AI program, unlike conventional computer programs 
which are highly formatted, will possess a large knowledge 
base of facts from which the attainment of goals is sought. 
The amount of information required to accomplish a given 
task is an area of major emphasis to AI researchers. For 
example, the difficulty in programming robots to process 
sufficient information and to perform even simple jobs lies 
in the total number of possible combinations of situations 
which may be encountered and therefore required to be stored 
in the knowledge base. Accordingly, the system must have a 
method for selecting from among the knowledge base facts to 
make appropriate inferences. 

This paper will explain a prototype decision support 
program, DECAIDS, and explain the necessary background and 
user information needed to use or expand the program. 

B. ARTIFICIAL INTELLIGENCE LANGUAGES 

As the study of AI has expanded, several programming 
problems have led to the search for new and more powerful 
methods for representing knowledge. Paramount among these 
difficulties has been the inability of existing languages 
to deal adequately with list processing and symbol manipu- 
lation. This fact has led to the development of several 
new programming languages, such as COMIT, IPL, LISP, 
INTERLISP, and SAIL to name just a few [Bobrow and Rafael, 
1974 ] . 
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This paper deals with INTERLISP as used by the EMYCIN/ 
DECAIDS program. The EMYCIN system was used to provide the 
inference engine (inference manipulation) for the prototype 
managerial decision aiding program DECAIDS. INTERLISP is 
a relatively easy language to learn and use because it is 
constructed of a simple syntax. It requires no previous 
knowledge of high-level languages such as FORTRAN or PL/1. 

There are about forty common functions in INTERLISP. 
Approximately one-half of these are highly mnemonic arith- 
metic operations. The remaining functions perform the other 
operations required for successful list processing and symbol 
manipulation [Winston, 1977]. 

The basic structure of INTERLISP is the symbolic-expression 
(S-expression) which is called a list of elements. These 
elements may be numbers or function names. This format 
of s -expressions can be readily adapted to the n-tuple 
concept described in the predicate calculus section of this 
paper. The following example has three elements. (The 
parentheses are required of all references to INTERLISP.) 
[Teitelman, 1974, p. 55]. 

(PLUS 3.14 2.71) 

In this example, PLUS is the addition function standing 
before the two arguments, 3.14 and 2.71, which are to be 
acted upon. This example also demonstrates the prefix 
notation which is used in INTERLISP (i.e., the function 
always precedes the arguments) . 
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C. KNOWLEDGE BASE 

The knowledge base, for an Artificial Intelligence pro- 
gram, is the data base supplied by an "expert" and operated 
on by a production system. This database is composed of 
an ordered string or strings of replacement rules. Design- 
ing and implementing a knowledge base requires the answers 
to some general problem-solving questions: 

What kinds of data are required? (specific 
facts or ideas ) ; how should the knowledge be 
represented? [Should the system query the 
user or vice versa? (EMYCIN takes the first 
direction toward deriving inferences.)] 

How much knowledge is required to cover the 
subject? (Specific, scientific subjects lend 
themselves far more readily to quantification 
than do more subjective domains.) And what 
is the required information? 

Finally, a knowledge base must be modeled and the tree 
of sub j ect -entities (contexts) arranged so that the questions 
asked about the domain are contextually sensible, that is, 
have some direction. It serves little purpose for the 
program to ask questions that have no direction. The 
knowledge base’s context tree must provide this understand- 
ing to the consultation-recommendation session. The questions 
asked during the consultation must be asked in a logical 
order to fill in the knowledge base. This can be partially 
accomplished by arranging the queries in an order that makes 
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the session flow in a smooth manner. When the entire context 
tree has been traversed, inferences are produced via the 
system's production rules. 

The EMYCIN system developed at Stanford University 
provides a framework for building consultation programs in 
any quantifiable field. The domain independent components 
of production rule systems and backward-chaining mechanisms 
manipulate the information in the knowledge base. More 
specifically, EMYCIN/DECAIDS uses an evolving knowledge 
base composed of declared parameters and rules for 
concluding goals. 

The knowledge base contained in DECAIDS is designed 
to support a prototype managerial decision aiding tool. 

While the recommendations rendered by DECAIDS are straight- 
forward, it must be remembered that the primary goal of 
this research was to demonstrate a capability of designing 
and implementing a decision support system based on AI . 

While previous AI research programs have been directed 
toward more structured applications, the current research 
investigates an area which is relatively unstructured and 
very subjective. Previous applications, for example, 
the subject of blood chemistry, will produce many specific 
statements and rules relative to the chemical conditions 
affecting a person's health. 

The system designer must know, and model, exactly what 
goal his system is to achieve before he attempts to write 
production rules. This requirement must be kept in mind 
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so that the knowledge base will be property supported by 
the elements of the knowledge base. The knowledge base 
contains two types of elements. These elements are rules 
and parameters which are used by the EMYCIN inference engine 
to support the search for a recommendation. 

Each of these elements is described by a list of its 
respective properties. The definition and instructions 
concerning these properties are contained in Section VII. 

The rules are the sentences, (If condit ion ... then action) 
statements, which imply the value (s) of parameters. The 
parameters are the nouns used in the sentences. One or more 
of these parameters will be identified as the root parameter(s) 
in the root context. The remainder of the parameters are 
used to help define, find a value for, this root parameter(s) . 
The rules are the statements which ask for the needed values 
and produce the recommendations. These questions may be asked 
either explicitly from the system user or implicitly from the 
system itself. 

The specific syntax for the rules and parameters are 
explained and demonstrated in following sections of this 
paper. The current knowledge base consists of forty-one 
rules and twenty-three parameters. 
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III. PREDICATE CALCULUS 



The predicate calculus is a system of logic in which it 
is possible to express complex logical statements as well as 
mathematical and natural language statements. The system 
has rules of inference that permit valid logical deductions 
of new statements to be made from a set of given ones. The 
most often used rule of inference is that of modus ponens . 
The inference rules produce well-formed-formulas from given 
ones. Predicate calculus' generality and logical power are 
important vehicles for performing deduction [Nilsson, 1978J. 

AI production systems are based on the formulas of the 
predicate calculus. A production is a rule consisting of a 
situation-recognition element and an action element. Thus 
a production is a situation-action pair in which the left, 
recognition, element is a list of conditions to ascertain or 
test and the right, action, element consists of a list of 
things to do or conclude. A list may contain only a single 
element. When productions are used in deductive systems, 
the situations that trigger a production, or rule, are 
specified combinations of facts. The actions are restricted 
to being assertions of new facts deduced directly from the 
triggering combinations. The productions may be called 
premise -conclus ion pairs rather than situation- action 
pairs. The action of triggering premises and conclusions 
is based upon the use of predicates and predicate logic. 
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Production rules are spoken of as "firing" which refers to 
the action taken by predicate functions [Waterman, 1976]. 

A programming language, using the predicate calculus 
logic, and specified by some syntax, is used to make asser- 
tions about some domain of interest -- to provide state 
descriptions about which some conclusions will be made 
[Winston, 1977, p. 257], The class of expressions referred 
to as well formed- formulas (WFF) is the basis for the asser- 
tion clauses of a particular language. The WFF's are used 
as the contents of a knowledge base and are permitted values 
of true or false. Techniques for manipulating WFF's permit 
an AI program to reason about a domain and ultimately make 
or reach a conclusion [Nilsson, 1979]. The method of opera- 
tion is that WFF's are applied, modify a knowledge base and 
eventually meet some termination conditions. 

The well-formed-formula (WFF) is given meaning by 
interpreting it (the WFF) as concluding some statement about 
a domain of discourse. For example, the domain of interest 
in this research is the set of statements concerning a 
decision support system. Conclusions drawn from this domain 
involve relationships among statements in the set of WFF's. 

The WFF's have values of true or false derived from the 
use of predicates (words or functions which direct some 
action be taken) whose values in turn may be true or false. 
The predicates perform the action of mapping elements of 
the domain (elements in the knowledge base) onto other 
elements of the domain (actually a local consultation or 
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session database). The WFF's are driven by the predicates of 
a language, the elements in the domain, and the relationships 
between the elements. 

Each WFF can be assigned a value of true or false and 
these values are used to obtain a final concluding value. 

The values for a WFF are referred to as certainty factors. 
Certainty factors are based on probabilistic reasoning and 
represent a rule weight assigned by a system designer or by 
an expert from whom knowledge base information has been 
obtained. The WFF (premise) which evaluates successfully 
provides a value between -1 and 1. Those rules with true 
premises have their actions evaluated and a conclusion is 
made with a certainty equal to the premise value times the 
certainty factor [Davis, 1977]. 

A. LOGICALLY FOLLOWS AS A PROOF 

The concept which allows a recommendation or conclusion 
to be produced is the idea of a WFF being a logical 
consequence of a given set of WFF’s. This is formally 
stated as the theorem of modus ponens which is: If a state- 

ment, A, is valid and A implies a statement, B, then B is 
valid. The premises of the production rules are the WFF's 
of the domain of discourse. These premises or WFF's may 
further be divided into clauses representing multiple con- 
ditions with each clause being evaluated for its true value 
[Nilsson, 1978]. 
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The implication o£ the preceding is that a "goal" in 
the EMYCIN system is the determination o£ the value o£ some 
parameter. This parameter's value is derived as a result o£ 
the in£erences o£ the WFF's. Each rule may have one or more 
clauses in its premise with the clauses o£ one rule joined 
by an "AND" £unction. All conditions in a single premise 
must be true in order to £ire the right-hand-side o£ a rule. 
The list o£ rules is a set o£ conditions joined by a 
logical "OR" Function. As such, any or all o£ the rules may 
succeed and give the subject parameter a value. Which value 
to present to the consultation system user is a combination 
o£ certainty Factors, probabilistic reasoning, and expert 
judgmental knowledge [Scott, 1979]. 
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IV. AND/OR TREES 



The concept o£ a tree-structured logic diagram is 
utilized in Artificial Intelligence applications to depict 
a graph of nodes representing state descriptions which are 
parameter values. A tree is referred to as a context (or a 
context tree depending upon the size of the domain of dis- 
course) and state descriptions are the parameters of the 
context. Parameters in turn may have sub-goals used to find 
out or trace their values. These sub-goals are additional 
parameters used in other rules. Values are determined by 
traversing the tree and applying rules. 

The tree traversal method used in DECAIDS is called 
"backward chaining" and is described as beginning a search 
at some goal state and proceeding to some initial state. To 
be more specific, the hierarchial structure of tree nodes, or 
state descriptions, where a node may have more than one 
parent, is properly called a graph. This may be the case 
with multiple rules applying to a specific situation. In 
the case of multiple rules, a control strategy must be 
implemented to select and execute rules in a logical manner. 
This control strategy must have some system for selecting 
relevant rules -- some special knowledge of the problem to 
be solved or how the program works. The control strategy 
used in EMYCIN and DECAIDS is the listing of sets of rules 
into groups pertinent to only certain states or declared 
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parameters. This grouping serves to focus the tree traversal 
towards the desired initial state from some goal state. 

The backward- chaining traversal method is used with AND/ 

OR trees. The name "AND/OR" is derived from the fact that 
the clauses in the action part of any rule are considered to 
be operated upon by an "and-ing" function. Separate rules 
in a knowledge base are considered to be operated upon by 
an "or-ing" function. The junctions of the rules clauses 
and the rules make up the nodes of the AND/OR tree. 

AND/OR trees facilitate control strategies in decomposable 
production systems such as DECAIDS. An explanation of a 
decomposable system follows: A rule application only affects 

that component of the global knowledge (accessible to all 
rules) used to state the rule's premise. The decomposition 
of the knowledge base is represented by an atom, one parameter, 
at a time being affected (modified, added, or deleted) . A 
primary benefit of the decomposable system is that redundant 
paths are not searched. 

An example of the decomposition of a production system 
is a rewriting rule such as B implies Cj which produces a 
string of all Cj's from some arbitrary string of capital 
letters. The objective is to establish the sequence of 
rewriting rules which produces the string of all Cj's. Each 
step in the sequence is a decomposed part of the system. The 
premise clause of a system's rules form the AND nodes and 
junctions of multiple rules form the OR nodes in a tree. 
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Those rules whose preconditions, or premise clauses, evaluate 
to true provide the path to a desired state [Nilsson, 1978, 
p. 1-52]. This structure of the AND/OR tree is used in 
DECAIDS to select relevant rules and to calculate the final 
strength of each rule. These strengths or weights are 
referred to as certainty factors. 

A. CERTAINTY FACTORS 

Certainty factors provide a methodology for quantitatively 
supporting the reasoning of production rules. A numerical 
value is assigned to each rule conclusion when that rule 
is added to the knowledge base. This is done by the rule 
writer. The value assigned is not considered to be a 
probability but more of some "expert's" judgmental reasoning, 
and values are permitted to range from minus one to plus one. 
The certainty factors are passed along an AND/OR tree in the 
following manner [Davis, 1977, p. 22]. 

The "and" function is a minimization function affecting 
production rules which contain one or multiple preconditions 
or clauses. Minimization is effected by the fact that the 
conclusion of a single production rule can never be stronger 
than the weakest piece of information. 

The "or" function is a maximization function. Accord- 
ingly, the certainty factors of multiple rules reinforce 
(or detract from) one another. From any "or" function the 
cumulative certainty factor is the algebraic sum associated 
with rules leading to that node. The final conclusion's 
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certainty factor is again the algebraic sum of the rule 
certainty factors leading to the root node. If a certainty 
factor falls below .2, an arbitrary threshold for EMYCIN/ 
DECAIDS, the conclusion is not utilized and the situation 
is considered as having no rule to conclude about it 
[Winston, 1977, p. 245], 
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V. PRODUCTION SYSTEMS 



As with conventional computer programs, Artificial 
Intelligence programs are characterized by data, operations, 
and a control strategy. An AI program is more specifically 
seen to have a global database, a production system of rules 
to accomplish operations, and a control strategy to determine 
which rules to apply and in what order [Nilsson, 1978]. 

A production rule program contains a set of rules. 

This program (DECAIDS) is the set of rules which is defined 
by some production system architecture (EMYCIN) referred to 
as a production system. Each of these rules has one or more 
preconditions to be verified. Upon verification of these 
preconditions (or premise clauses), the rule's conclusion 
statement will be executed. Information in a knowledge base 
may be modified, deleted, or added by the action of a rule 
[Waterman, 1976, p. 3]. 

In affecting parameter values, rules are considered to ^ 
be modularized pieces of coding and distinct pieces of infor- 
mation. Each is a separate "chunk" of knowledge used in the 
program [Davis, 1977, p. 7]. In performing operations on a 
knowledge base, rules are controlled by a rule monitor and a 
rule interpreter. A rule monitor is a subroutine designed 
to affect the desired control strategy while a rule inter- 
preter is a subroutine called by the monitor to execute 
rules and, thereby, determine the values of parameters. 
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These functions will be explained in detail later in 
this section. 

When individual rules modify the knowledge base, no 
extensive changes to program code are necessary because 
each rule is modularized. However, it must be noted that 
while the rules and parameters may be added or deleted 
without requiring any changes in the knowledge base, their 
additions or deletions may affect the logic required to 
present a complete path of question-asking reasoning to a 
root node. Due care must be exercised not to disturb 
the backward-chaining path used to reach a logical conclusion. 

In using a production system to address a problem, three — 
areas must be addressed: problem states, the rules, and 

termination conditions. Problem states are the total number 
of alternative solutions possible to achieve a goal. This 
may also be referred to as the problem space. These alter- 
natives must be formulated into some standard computer pro- 
gramming data structure for program use. Lists have been 
used by Artificial Intelligence programmers as the most 
appropriate data structure. Accordingly, LISP and INTERLISP 
are currently the most often used languages for AI applica- 
tions. State descriptions serve the purpose of describing 
rule preconditions. The approach to a problem in an AI 
program is through a sequence of state descriptions and rule 
applications which modify a knowledge base to arrive at some 
termination condition. The rule monitor is responsible for 
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recognizing the termination state or condition as specified 
by the system designer. 

The control strategy has the responsibilities of 
selecting rules, accounting for problem states (parameter 
values), and accounting for rule usage. There are two basic 
control strategies: irrevocable and tentative. The 

irrevocable method applies a rule with no reconsideration 
of its effect on a knowledge base. An example of a tenta- 
tive system is the backward-chaining used in DECAIDS. 
Reconsideration of a rule's effect is seen as the continual 
computation of certainty factors along a traversal of the 
AND/OR tree. Control strategies may further be explained by 
describing two types of production systems, condition- 
driven and action-driven [Nilsson, 1978, p. 1-22]. 

A. TYPES OF PRODUCTION SYSTEMS 

In general there are two types of production systems: 
condition- driven and action-driven. The method of inter- 
action with the knowledge base is the deciding factor between 
the two. In a condition-driven system, the conditions of 
the premises are compared to the database and the rules 
whose conditions match the database are chosen to have their 
Right-Hand-Side (RHS) executed. The action-driven system 
interacts with the knowledge base by first checking the RHS ' s . 
This procedure parallels a logical implication with its "1 
and 2 imply 3" statements. The system attempts to prove that 
3 is true by checking for 3 in the database and, if this is 
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false, then proving that 1 and 2 are true -- therefore 3 is 
true -- and adding 3 to the database [Waterman, 1976, p. 3], 

A conflict set, in a condition-driven system, is the 
collection of all rules whose Left-Hand-Sides (LHS) have 
proven true. Selection of the appropriate rule to execute 
is an action called conflict resolution. The most often 
used technique is rule ordering where each rule is previously 
assigned some priority value and the rule with the highest 
value is executed. 

EMYCIN and DECAIDS are primarily action-driven systems. 

A premise is presented to the system to be evaluated either 
true or false. The premise may be proved true by the user 
providing an answer to a question or through deductive 
inference. The method for proving the premise is to examine 
the actions of rules to find one which would make the premise 
true. All clauses of the premise must prove true. The 
following is an example of an action-driven problem solution: 
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The goal is to prove H true. The system first checks the 
database to find H. If this fails, which it does here, the 
system tries to deduct that H is true by using the rules 
that contain H on the RHS's. The first relevant rule is 7. 

G is next sought in the database since if G is in the data- 
base then H is true. Therefore, rules containing G must 
now be tried. Rules 2 and 3 apply and these may be assumed 
to be rule ordered. D and F must be proven and this is 
accomplished via proving A true in the database, B and C are 
true from 5 and 4, and, finally, D and F are true, G is true 
and H is true. As the rules are executed, the newly proved 
elements are added to the database [Waterman, 1976, p. 6]. 

This simple example of an action-driven system should be 
kept in mind when the reader begins to write rules, complete 
the knowledge base, about a specific domain of information. 
More specifically, the source of a value for a parameter 
should be considered -- from the user or from a knowledge 
base search. 

B. THE EMYCIN INFERENCE ENGINE 

Researchers in Artificial Intelligence have recently 
attempted the solution of some real-world problems. Infec- 
tious blood diseases, pulmonary functions, aircraft wing 
structural analysis, and decision aiding systems are a few 
of the subjects considered relevant for AI applications. In 
each of these areas, large amounts of task-specific knowledge 
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must be collected to build a knowledge base. This information 
is only available from ''experts" making assertions about a 
particular subject or through research. However, an Arti- 
ficial Intelligence program must provide the desired utility 
before it will draw an interest. It must also be provided 
with a method of maintaining an evolving body of information. 
The use of production rules aid these two AI design criteria 
[Davis, 1977]. 

This thesis includes an example of an interactive 
decision aiding program (DECAIDS) , designed to assist the 
middle/top- level manager or commander in making decisions 
concerning acquisition and use of automation within his 
organization, and when given certain organizational charac- 
teristics, to determine an appropriate organizational 
structure. Additionally, the method of data acquisition 
which provides for a system creditability and maintains an 
evolving knowledge base will be explained. The "Essential" 
MYCIN (EMYCIN) inference, production rule, engine is the 
programming vehicle used to accomplish deductions and pro- 
duce conclusions in DECAIDS. (The name MYCIN was given to the 
production rule program which was first concerned with infec- 
tious blood diseases because many medicines ended with the 
suffix "-mycin.” EMYCIN is an extension of the original 
system to other domains. The term "inference engine" refers 
to the concept of EMYCIN being a soft machine which produces 
inferences.) [Scott, 1979]. The inference engine modules are 
depicted in Figure V-1. 
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Figure V-1 

Inference Engine Modules 
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The advice sought from the system is provided by the 
interactive consultation session. Three other system 
utility programs exist for extending the knowledge base 
(the acquisition program) , for providing reasons for a 
conclusion (the explanation program) , and for answering 
natural language questions about the knowledge base (the 
question-answering program). The question-answering program 
requires an extensive library of domain definitions and is 
currently not in use in EMYCIN. These modules occupy a 
total of 130K of nonshared code, are written in INTERLISP, 
and run fast enough for real-time interaction [Davis, 1977]. 

The DECAIDS domain specific knowledge consists of less 
than 50 production rules. Each rule contains, as mentioned, 
a premise and an action. The premise is a Boolean combination 
of predicate functions on associztive triples with each 
premise clause containing a predicate function, an object 
(context), and an attribute (parameter) value. An example of 
a clause in English is: 

"If: The structure of organization is line," 

and in INTERLISP syntax is , 

"($AND (SAME CNTXT STRUCTURE LINE))" 

The "then" part of the rule is the conclusion statement. 
Appendix E contains a listing of the standard predicate 
functions used in premise and conclusion statements. The 
premises are evaluated in INTERLISP to test for their 
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validity and the conclusion action performed if "true" is 
the premise value. Known conditions are saved in the 
"session database" by a rule adding that condition [Davis, 

1977] . 

1 . Rule Invocation Procedures 

Rules are called in a backward-chaining manner which 
produces a depth-first search of an AND/OR tree, e.g., this 
search proceeds down the branches of a tree first rather 
than across. When given a goal to achieve, the system 
retrieves the list of rules whose conclusions bear on the 
goal -- the right-hand- sides are scanned and the goal sought 
for in the knowledge base by the monitor subroutine. The 
INTERLISP function "EVAL" is the rule interpreter for 
evaluating the premise of a rule. (In INTERLISP, an "s- 
expression" is an atom or may be a list; "s" is an abbreviation 
for "symbolic." An EVAL function in INTERLISP returns the 
value, TRUE or NIL, of an evaluated s -express ion. ) [Winston, 
1977, p. 266]. No additional work is required. Rules whose 
premises are evaluated false are bypassed and those for which 
an answer cannot be determined have sub-goals created for 
them and a rule search recurs. 

These sub-goals take the form of "find the value of the 
parameter" of the premise. "By setting up the generalized 
goal of collecting all evidence about a parameter, the program 
exhausts each subject as it is encountered and tends to group 
together all questions about a topic. This presents a more 
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orderly approach to the problem." [Davis, 1977, p. 9]. 

If after trying all relevant rules about a sub-goal, the 
certainty factor associated is still between -.2 and .2, 
then the sub-goal is still considered as unknown. "This 
may happen if no rule were applicable, the applicable rules 
were too weak, the effects of several rules were offsetting, 
or if there were no rules for the sub-goal at all." [Davis, 

1977, p. lOJ . emYCIN provides the pattern matching capa- 
bilities and INTERLISP provides the evaluating functions -- 
the user or system writer, who completes the knowledge base, 
must furnish all concluding rules. If no value can be 
deduced, then the user may be asked for a value. A value 
may be an alphabetic value. A "?" will present a list of 
acceptable values to the user during a consultation. 

In some cases , the user is assumed to always have 
the answer to certain questions for which there should be 
no need to spend time searching. Name, rank and social 
security number are examples of such information. In this 
case, where the user is immediately expected to provide a 
parameter value, the answer to a question, that parameter is 
declared with a property called LABDATA. This LABDATA 
property will have a value of true declared and the user 
will be prompted with a plain language text question request- 
ing the subject parameter's value. This plain language text 
question is maintained in a parameter property called PROMPT 
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and the acceptable or permitted values for a parameter are 
kept in a property called EXPECT. 

In the interest of efficiency, rules are "previewed" 
for clauses whose values are already known and would thus 
make the entire premise false. There would then be no need 
to evaluate this rule. When running a consultation with the 
highest level fault trace turned on (FT4) , a rule found 
false during this preview will receive the following message: 
"Rule #, Failed in Preview Due to Clause #." The Boolean 
logic for this situation is False and True = False. 

The "previewing" facility is accomplished with a data 
structure called a template used with each predicate func- 
tion. Each template has the basic form of (function-context- 
parameter value) and uses internal flags to determine if a 
parameter has been previously used with this function and 
whether it is true or false in this clause. 

The last action seen during rule invocation is the 
use of antecedent style or definitional rules. If a conclu- 
sion is made which matches the premise, these antecedent 
rules are invoked with a certainty factor of 1.0. After 
desired parameter values have been determined, an antecedent 
rule is used to produce the system's output, i.e., once the 
parameters describing the context ORGANIZATION are known, then 
an inference can be made with a definitional rule recommending 
the organization should use a particular type of computer 
installation [Davis, 1977]. 
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c. DATA ACQUISITION 



Since any domain of information can be expected to 
change, a capability to add and delete pieces of knowledge 
must be provided. The updating of an evolving knowledge 
base is necessary to give the subject system acceptability 
and recognized competence [Williams, 1978, p. 3]. The 
addition of knowledge to a system is accomplished by the 
system writer or user producing the production rules using 
the INTERLISP syntax described later. EiMYCIN and DECAIDS 
scan new rules provided by the expert to find key words 
which indicate the appropriate predicate functions and a 
template, function-context -parameter-value tuple, to be 
retrieved. Values provided for the parameters must be a 
member of the parameter's EXPECT property, the list of per- 
mitted or expected values for that parameter. Upon comple- 
tion of the parse of the rule, the new rule is added to the 
appropriate list of relevant rules of the same rule group 
[Davis , 1977, p. 25] . 

When adding new rules, direct contradictions should be 
avoided. While the certainty factor computations will 
provide a resolution, the strength of the consultation 
recommendation will be weakened by contradicting rules. 

New values and parameters must also be updated tliroughout 
the information structure of the system. While new rules 
may be added without regard for deleting old ones (only the 
true, relevant rules will be executed), parameter values 
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must be kept abreast of current technology. Finally, the 
additions of not just a single rule but the addition of an 
entire concept must be carefully planned when being added 
to a knowledge base. A single rule is easily expressed and 
added to the program. However, a set of rules, stated in 
the backward'chaining , goal-directed, manner is not a normal 
human method of expression. Due care must be exercised in 
writing a logical ordering of rules to achieve a complex 
concept or goal. Written first in the system writer's 
natural language (i.e., English) the question asked of the 
user (or implicitly of the system) will be the rule concluding 
the parameter values. 

This is an example of the modeling process used to write 
production rules and fill a knowledge base. 

1. A system designer has been tasked to accept ideas 
from an organizational theorist and information analyst and 
to produce production rules leading to a recommendation 
concerning computer resource utilization. 

2. It has been decided that STRUCTURE, the name of an 

organization, may have one of two possible organizational 
types: LINE or MATRIX. STRUCTURE, LINE and MATRIX will be 

used by the system designer as parameters in the knowledge 
base. LINE and MATRIX are values for the parameter STRUCTURE. 

3. It has further been decided that if STRUCTURE has 

the value of LINE, then the organization is recommended to use 
a large computer, graphic display, and batch processing 
capabilities . 
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4. Accordingly, the system, designer decides to declare 
SIZE (of the computer), TYPE (of display), and MODE (of 
processing) as parameters with values of large or small, 
printer or graphic, and interactive or batch, respectively. 

5. The system designer next verbalizes a premise: 

If the structure is line 

(and, next he verbalizes an action) 

Then strongly suggest a large computer be used 
(cf .8) 

strongly suggest graphic terminals be used 
(cf .8) 

strongly suggest batch processing be used 
(cf .8) 

6. Finally, the rule is written in INTERLISP syntax: 
($AND (SAME CNTXT STRUCTURE LINE)) 

(DO-ALL (CONCLUDES CNTXT SIZE LARGE TALLY 800)) 
(CONCLUDE CNTXT TYPE GRAPHIC TALLY 800)) 
(CONCLUDE CNTXT MODE BATCH TALLY 800)) 

7. The phrase "TALLY 800" is the required certainty 
factor syntax. 

D. BASIC SEARCH METHOD OF EMYCIN/DECAIDS 

Searching in EMYCIN/DECAIDS is entirely a goal-directed, 
backward -chaining process. Each "goal" is to determine the 
value of some parameter. The chaining starts with the 
parameter which the system builder specifies as the goal 
of the consultation. This is the value or values in the 
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GOALS property of the root context type. This GOALS 
property is actually a list of parameters and each one is 
traced in turn. 

To trace or determine the value of a context parameter, 
the control structure accomplishes the following: 

-- If the parameter's LABDATA property is "T," then the 
value is requested of the consultation system user. If 
the user responds UNKNOWN or enters a certainty factor (cf) 
less than 1.0, and if there exist rules that conclude the 
parameter, then these rules are tried. Once all rules have 
been tried, the system knows as much as it ever will about 
that parameter. If the parameter does not have a "T" value 
for the LABDATA property, the rules are tried first. After 
all have been tried, and still nothing is "known" about the 
value or the parameter has a PROMPT, the user will be asked 
the question (text) in the PROMPT property for which , certain 
answers (values in the EXPECT property) are allowed. Here 
"known" means a cf greater than .2 for non-yes/no answers 
and a cf greater than .2 or less than -.2 for yes/no parameters. 
When all of this has been accomplished, the system knows as 
much as it ever will about that parameter. 

The previously described apparatus is called the FINDOUT 
mechanism and is written in INTERLISP. The process of trying 
a set of rules is called the EMYCIN MONITOR mechanism and 
works as follows : 

The system starts with the first rule in the list. The 
UP-DATED-BY property of a parameter is the list of rules 
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that can be used to conclude about the parameter. This 
UP-DATED-BY property is compiled by the GETRULES, rulewriting, 
program. The UP-DATED-BY property is the list that is used 
by the MONITOR mechanism when the MONITOR is used to find 
out a parameter value. 

Each clause in a rule's premise is evaluated. If a 
clause mentions a parameter which has not yet been traced, 
then the FINDOUT mechanism is used to trace it. This is 
where the backward-chaining is demonstrated. The system 
now suspends what it is doing and sets up a sub-goal, i.e., 
to find out the parameter that is needed in the rule currently 
being processed. The backward-chaining drives the consulta- 
tion: It is what causes all questions to be asked with the 

exception of the PROMPT’S of the parameters in the MAINPROPS 
property of the contexts. 

-- If the clause that is being . evaluated fails, then 
the rule is discarded and the system MONITOR mechanism pursues 
the next rule in the list. If the rule succeeds, then the 
next clause of the premise is evaluated. When there are no 
more clauses to be evaluated, execution of the ACTION clause 
occurs . 

-- If the value of the parameter is known with certainty 
(cf = 1) then the system seeks no further, and goes on to the 
next rule having executed the action. The entire process 
continues until each rule in the list has been tried. 

The only exception to backward- chaining is in ANTECEDENT 
rules. These are rules that are tried as soon as all the 
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parameters in the PREMISE are traced as opposed to the rest 
of the rules which are tried in order to find out the value 
of the parameter in their ACTIONS. On the property list of 
a parameter the ANTECEDENT-IN property is a list of ante- 
cedent rules to be tried when the parameter has been traced. 
Once the parameters have been traced, the rule is executed -- 
often .in an output type statement [Scott, 1979] . 

E. PARAMETER TRACING IN A CONTEXT TREE 

EMYCIN/DECAIDS performs the following actions in order 
to trace the value of a parameter, called "PARM” in this 
example, in a context, called "CNTXT." The rules in the 
parameter's UP-DATED-BY property are tried one by one. The 
rules are listed in the UP-DATED-BY property by the GETRULES 
subprogram. When trying a rule, called "RULE," its SUBJECT 
called "GROUP," in this example, is compared to the context 
type of "CNTXT," called "TYPE." "GROUP" is the value of 
RULE'S subject property and is a member of the list called 
ALLNAMES -- the name of the list for rule groups. "TYPE" 
is the value of "CNTXT 's'* PROPTYPE property. This value is 
"PROP-VAL" for all contexts. 

The CONTEXT property of a rule group is the list of 
context types to which RULE can apply. By convention, a 
rule may reference parameters of the context to which it 
applies and parameters of descendent contexts. It may 
not reference parameters of contexts lower in the tree -- 
nearer the root. Therefore, if a rule is relevant to CNTXT, 
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one of two conditions may apply. The RULE may apply 
directly to CNTXT, and in this case, the CONTEXT property 
of GROUP must contain TYPE and the RULETYPES property of 
TYPE must contain GROUP. The other possibility is that RULE 
applies to a descendent of CNTXT. TYPE'S OFFSPRING property 
is the list of context types that may be below CNTXT in the 
tree. The system examines each of the OFFSPRINGS of TYPE 
(and succeeding OFFSPRING) to try to find a descendent con- 
text type to which RULE can apply. If any such lower context 
is found, then the RULE is relevant. Relevant descendents 
of CNTXT are collected and RULE is applied to each of these 
contexts [Scott, 1979]. 

F. INTERPRETING THE PRODUCTION RULE PROGRAM 

The interpretation of a production rule system is com- 
paratively simple. The procedure involves a search through 
the knowledge base for a production that matches the pro- 
duction in the consultation data-base. DECAIDS moves back 
and forth searching for the relevant production and execu- 
ting the rules which are true. The action of searching for 
a rule is made a little easier through the ease of pattern 
matching in LISP and INTERLISP. LISP has no organic pattern 
matching capabilities but can be easily programmed for this 
task. The basic LISP function which facilitates this in- 
terpreting is called COND. COND is the LISP branching 
function or conditional function. The COND function is 
followed by a list of premise clauses to be tested. The 
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pattern matching occurs at this time with the system, 
checking in accordance with the GETRULES ”used-by" property, 
looking for key, or matching, expressions. More specifically, 
a function is DEFINE 'd in LISP which examines the elements 
of the rules in the knowledge base and the consultation data- 
base. ("DEFINE" is a LISP function which permits a 
function declaration. If a match is made, a recursive call 
is made on the remainder of the rules to be matched. If 
NIL is returned, then the next clause is examined [Winston, 
1977] . 

G. PROS AND CONS OF PRODUCTION SYSTEMS 

There are several advantages and some disadvantages in 
using the production rule architecture. Production rules 
represent a form of code modularization. Each production 
rule is a self-contained, modular piece of code independent 
of other rules in execution. The advantages of modular 
coding are well known. Such a technique greatly aids the 
task of managing very large and/or evolving database. 

Parsing new rules to be added to the appropriate internal 
lists, relevant to a goal, is made easier. The production 
rules are a succinct form of knowledge representation. Each 
is easily written and retrieved. Unlike other high-level 
languages, no changes in previous coding need be made in 
order to add new rules. No other rule must be altered to 
ensure that the new one will be called and executed 
[Winston, 1977]. The use of the RULE GROUP and PROPGROUP 
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properties and the key word search of the function-parameter 
templates ensures that only relevant rules are executed 
[Scott, 1979] . 

A disadvantage in the use of production rules is the 
difficulty in expressing series of rules to convey a complex 
concept. The modularized, "if-then" coding does require 
some practice in the area of "backward -thinking . " The rule 
writer must be cautious of the goal-directed invocation of 
rules in preparing the rules [Winston, 1977, p. 151]. 
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VI. DECAIDS KNOWLEDGE BASE 



A. BACKGROUND 

The birth of decision making as a discipline can be 
traced to early operational analysis techniques employed 
during World War II [Williams, 1978, p. 4], More recently 
there has been considerable debate between behavioral 
scientists and technically-minded analysts concerning just 
what decision making is. Behavioral scientists believe 
that decision making remains the province of organizational 
behavior and theory. This point of view differs drastically 
from that of the more technically-minded analysts who 
believe that this discipline is better founded in quantita- 
tive methods such as operations research and management 
science. The differences between these viewpoints clearly 
point to the fact that ’’decision making theory" remains 
relatively unformulated [Williams, 1978, p. 4]. 

The capabilities of automatic data processing techniques 
in operational and management tasks (accounting routines, 
record keeping, operations control, etc.) are well known. 

The use of these techniques by mid- and high-level managers 
beyond these "bookkeeping" areas is not yet significant. 
There are two major reasons for this lack of use by manage- 
ment to assist in decision making. One is the inability to 
adequately transfer new technologies from the research/ 
academic areas to the manager. However, the primary reason 
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for the manager's point of view may be the lack of a model 
which describes the organization status or situation. 

B. MODEL DEVELOPMENT 

The prototype program (DECAIDS) , as described in this 
paper, represents an attempt to identify the key parameters 
affecting organizational managers and the decisions which 
they must make. More specifically, this decision support 
program, DECAIDS, attempts to "quantify" these parameters 
in order to deduce recommendations concerning appropriate 
computer system capabilities. These recommendations are 
based upon organizational characteristics described by the 
user. 

The DECAIDS knowledge base was developed from the final 
technical report prepared for the Office of Naval Research 
by Spector, Hayes, and Crain. This report evaluates the 
effects of computer-based decision aids on organization 
structure. It was chosen as the basis for DECAIDS because 
it specifically addresses the subjects of decision aids and 
organizational structure. The knowledge base is not con- 
sidered comprehensive; rather it is a skeleton which can 
be further expanded by subsequent research. 

The current knowledge base (Figure VI -1) has ORGANIZA- 
TION as the root context. This context is defined by the 
organization's structure and environment. The following 
sections of this chapter describe the current system 
parameters and the ultimate recommendations which are 
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reached during the interactive consultative session(s). 

During the following discussions, DECAIDS program parameters 
are indicated in capital letters. 

1 . Formal and Informal Organization Structure 

"Organization structure is concerned with the role 
and personal arrangements within an organization that 
specify authority, coordination, and communication rela- 
tionships. These arrangements link functions and physical 
factors to manpower requirements and availability." [Spector, 
1978, p. 31]. Simply stated, this organizational structure 
relates to the internal system of functioning groups -- 
the processes by which the organization operations are or 
should be accomplished. The organizational structure can 
be further subdivided into the formal and informal structures. 

The formal structure (FORMAL) involves the official 
patterns of authority and the location of responsibility 
and accountability within the organization. Public and 
private sector usage has resulted in the identification of 
four basic formal structures. These four categories define 
the different lines of command and control, advisory, and 
functional relationships. The four basic formal structures 
used in DECAIDS are; line, line and staff (called staff), 
functional, and project manager (called matrix) [Spector, 

1978, p. 3-2] . 

Line structure emphasizes direct chains of authority 
and unity of command while the line and staff includes an 
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informational and/or advisory staff to assist/guide line 
or operational personnel. A functional structure organizes 
personnel by functional activity or type of task, such as 
supply, planning, or communications functions [Spector, 

1978, p. 3-2]. Finally the project manager (matrix) structure 
organizes specialists from specialized organizational units 
to work together with other specialists. "For example, 
chemical, mechanical, industrial, and electronic engineers 
may work together in a team with physicists, accountants, 
human engineers, and other professionals to develop a new 
product." [Tosi, 1976, p. 471]. In this structure, the 
individuals work to achieve the interdepartmental goals. 

The informal structure (INFORMAL) describes the 
system of transactions, dynamic and interpersonal, which 
occur within an organization. These informal processes, 
patterns, and relationships develop quite naturally as 
organizational personnel interact to handle the problems 
and requirements of their roles in their own particular 
styles. While the organization's formal structure estab- 
lishes the division of labor within the organization, the 
informal structure identifies the reality of organizational 
behavior and performance based upon the individuals involved. 

Spector e_t al. (1978) identified five informal 
structures. These five informal structures which have been 
used in DECAIDS are; centralized, consultative, transac- 
tional, partially-delegated, and decentralized. A centralized 
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structure employs a focused flow of authority to a single 
source at the top of the hierarchy. Consultative - type 
informal structures maximize patterns of central control, 
but encourage vertical, upward communication of advice/ 
guidance from the professional staff. Open communication, 
deliberation, and negotiation, not only vertically among 
hierarchial levels but laterally among levels is highly 
encouraged by transactional structures. This type structure 
does not preclude the ultimate decision remaining with the 
high levels of the hierarchy. Another form of informal 
structure promoting management by negotiation is the 
partially-delegated structure. This system distributes 
authority among the professional staff while increasing the 
need for coordination of effort. Under this arrangement, 
staff personnel have authority to develop action alterna- 
tives with top management retaining the right to approve, 
reject, or modify these options. Finally, the decentralized 
structure uses a high degree of delegation and dispersal 
of decision making authority to lower levels of the higher 
hierarchy. 

Formal and informal structures represent the 
theoretical and realistic arrangement of organizations, 
respectively. Formal structure defines a set of decision 
methods and procedures designed by management in order to 
optimize the performance of the organization. The formal 
structure that is chosen reflects the past management 
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experience and is based upon the expected personnel 
configurations. The informal structure defines the actual 
decision methods and dynamic problem-solving processes that 
are used to motivate organizational performance. 

In reality, these informal structures may exist in 
a myriad of combinations and variations. DECAIDS uses them 
individually and independent of one another. This program 
also offers the user the additional choices of declaring 
both formal and/or informal as not known (notavailable) . 

If this option is used, the program contains production rules 
which will return suggested configurations for formal and 
informal structures. 

2 . Environment 

The other parameter affecting organizations is the 
environment in which the organization must operate. There 
are three basic factors which make up this environment. 

They may be described as; the mission to be accomplished, 
the personnel required to perform the mission, and the 
technology available to perform the mission. 

The model defines the mission in terms of problem 
definition (PROBDEF) and stress level (STRESS) . The user 
is asked to define the task in terms of problem definition, 
either clearly defined or ambiguous. Mission stress is 
defined as high, low, or unknown. 

Personnel environment is divided into two categories 
concerning the leader and staff. The system currently 
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contains only two parameters related to the leader. These 
are the leader's style (STYLE) and his level of training 
(LEADER-TRAINING). Leader style is defined as either 
relation-oriented or task-oriented. Relation-oriented refers 
to the leader who gives "little direction to his staff, 
encourages them to actively participate in setting decision- 
making parameters, and values the development of personnel 
responsibility, decentralized informal organization structures 
provide maximum performance." [Spector, 1978, p. 4-20]. 
Conversely, task-oriented leaders are defined as those who 
prefer far more centralization or consultative structure 
and are less concerned with the development of individual 
responsibility in the decision-making policy. Leader- 
training relates the level of training in the use of the 
computerized technical aids which the mission leader 
currently possesses and is defined as either skilled, 
unskilled, or unknown. 

The staff environment is currently defined by only 
one parameter, staff- training (STFFTRG) . This parameter 
relates to the staff's level of training in computerized 
technical aids and is either skilled, unskilled, or unknown. 

The available technology relates to three parameters: 
computer system status (SYSSTAT) , the technical knowledge 
level required to perform the mission, and the purpose of 
the system's use (METHODS). The first parameter, computer 
system status, refers to the implementation or operational 
status of the organization's computer assets. The only 
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alternatives currently offered are: yes, an operational 

system is in existence, or no, there is none in operation. 

The alternatives allowed for knowledge level are skilled or 
unskilled. The other parameter used to define technological 
environment deals with the use of the system. The current 
accepted responses are inventory aids or analytical aids. 
Inventory aids refer to the more administrative type uses. 
Analytical aids are those which concern more scientific 
applications . 

3 . DECAIDS Program Goals 

The program which has been developed is currently 
designed to support three goal parameters. These goals are 
decision aid characteristics (DECAIDS), formal structure 
(FORSTRUC) , and informal structure (UNSTRUC) . Successful 
inference of the first parameter, DECAIDS, is the primary 
goal of the current program. The interactive session 
between the program and user is aimed at deducing the most 
appropriate decision aid characteristics based upon the 
invoked program production rules which in fact reflect the 
user's decision making environment. 

DECAIDS is composed of four parameters that define 
various characteristics of computer decision aids (Figure 
VI-2). The current definition includes the recommended type 
of computer system (TYPSYS) , output devices (OUTPUT), 
computer installation arrangement (INSTALL), and the best 
training/assistance alternatives for successful implementation 
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DECISION AID CHARACTERISTICS (DECAIDS) 
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(TRG) . The current type systems recommended are real-time 
and non real-time. The output devices are either individual 
terminals or large screen displays. The possible installa- 
tions are divisional and pyramidal. Divisional installation 
places authority in each division for independent systems 
while pyramidal installation places authority at the top of 
one super-system above all divisions. The final parameter 
reflects the training needed or assistance required by the 
organization in order to implement a computer based decision 
aiding system. 

The two other goal parameters, referring to formal 
and informal organization structure, are invoked when the 
user responds that either or both of these structures are 
not available. When this answer is indicated, production 
rules for FORSTRUC and/or UNKSTRUC result in the recommenda- 
tions for the use of either line and/or centralized structures 
are made . 



54 



VII. TUTORIAL 



A. OBJECTIVES 

The EMYCIN system was designed and implemented by a 
research group at Stanford University, Palo Alto, California. 

It contains the essential components needed to create and 
support an interactive consultation program. These essential 
components are the consultation program, predicate functions 
and their translations, the explanation subprogram, and the 
question-answering subprogram. (This last feature is currently 
not functioning in EMYCIN.) The subject domains of the program 
range from human blood disease diagnosis to structural analy- 
sis [Scott, 1979]. The domain of the prototype program 
developed in this paper is decision support system charac- 
teristics and is named "DECAIDS." In order to implement 
this domain, a knowledge base was created and fitted into 
the EMYCIN format. 

The objectives of the tutorial follow: 

1. Introduce the computer-naive user to the EMYCIN 
system and the DECAIDS program. 

2. Provide users with the required background and 
documentation in order to further develop DECAIDS or 
develop a unique program of their own. 

3. Demonstrate the basic features of a knowledge base 
system through the use of a very simple prototype system. 
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4. Introduce the INTERLISP programming language and 
provide users with sufficient information concerning its 
syntax and functions for use with the DECAIDS program. 

5. Produce an interactive system which will provide 
managers with recommended decision aid characteristics based 
upon their individual organization structure and environment. 

The first and second objectives are related and will 
provide users with the more basic concepts involved in 
producing a working system. It is assumed the user does not 
possess a background in computer science and every effort 
will be made to explain these concepts in an understandable 
manner . 

This tutorial is intended to provide an introduction to 
the use of INTERLISP. The documentation contained in the 
tutorial and Appendices F and G is intended to furnish users 
with sufficient knowledge of INTERLISP so that they can work 
with the DECAIDS program. 

Finally, the use of the prototype DECAIDS program 
demonstrates knowledge base features and provides the 
basis for the fifth objective. It is anticipated that the 
DECAIDS program will be greatly expanded and improved by 
future users. 

B. KNOWLEDGE BASE SYSTEMS 

The building blocks of the knowledge base are contexts, 
parameters, goal -parameters , and production rules. The first 
step in the creation of a knowledge base is the creation of 
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the tree structure which represents the subject domain. 

(Figure VI-1 provides the logical tree structure or knowledge 
base of the DECAIDS program.) The selection of the subject 
creates the root-context for the context tree. The root 
context will have one or more goal-parameters which represent 
the ultimate "recommendations" to be inferred from production 
rules. The various branches of the context tree are repre- 
sented by parameters used to describe the subject domain of 
the tree. The ultimate objective is to write a set of 
production rules which relate parameters with appropriate 
goal-parameters. Goal-parameters can be defined as those 
parameters which are concluded from the production rules . 

This objective is accomplished by writing questions about 
the system parameters in natural language (i.e., English). 

The responses to these questions will constitute the infor- 
mation contained in the knowledge base. 

The system parameters must be declared next. Section C 
of this chapter and Appendix D contain definition and examples 
of the various parameter properties. These properties must 
be provided by the system designer when the parameters are 
declared (entered on the computer system). 

The knowledge base system production rules are written 
in the following format: 
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value ^ and 



If: parameter^ = 

parameter 2 = value 2 and 

parameter^ = value 
^ m m 

Then: goal-parameter^ = goal-value^ (cf) , and 

goal-parameter^ = goal-value^ (cf) . 

Each value for the goal-parameters will have its own certainty 
factor (cf) assigned. A certainty factor is a relative weight 
based upon probabilistic reasoning by the expert who provides 
the knowledge base. In EMYCIN/DECAIDS , these certainty factors 
range from -1.0 to 1.0 in increments of 0.1. 

The successful construction of a knowledge base depends 
greatly on the fact that conditional statements are related 
to all of the declared parameters. These conditional state- 
ments are actually a set of backward- chaining rules which 
eventually conclude the declared goal-parameter (s) . For 
example, one of the DECAIDS program current goal -parameters 
is "DECAIDS.” Therefore, production rules must eventually 
assign "DECAIDS" some value, i.e.. 

If : Parameter X is Value Y 

Then: Conclude "DECAIDS" equals (recommendation). 

The value of parameter X is provided to the program during 
the interactive session. The recommendations for this 
particular goal -parameter (DECAIDS) consist of the four 
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parameters called TYPSYS , OUTPUT, INSTALL, and TRG. These 
parameters are more thoroughly explained in the preceding 
chapter . 

The successful implementation of this type system depends 
upon providing a chain of reasoning that will "find” parameter 
values which lead to the "selection" of desired goal -parameter 
values. This can be accomplished by first writing the con- 
ditional statements related to parameters that will conclude 
the goal-parameters in English. From this format these rules 
can easily be transposed into the INTERLISP language. The 
EMYCIN monitor selects the order in which conditional state- 
ments will be processed. The system designer can control the 
direction of the interactive session by ordering the parameters 
(of the context's MAINPROPS property) in a manner which makes 
the session flow easily. This is accomplished because the 
system asks its questions (PROMPTS) in the same order that 
these MAINPROPS are listed. 

C. SYSTEM PROPERTIES 

The following properties are used in the EMYCIN/DECAIDS 
program. They are used to implement system additions after 
the appropriate production rules have been written. 

1 . Contexts 

The knowledge base is centered around the "object- 
attributed- value" triples. The object portion of this triple 
is the context. A context is some entity made up of related 
parameters. Each system that is constructed must have at 
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least one context (or root) which is the subject for that 
system. 

In DECAIDS, the context is '’ORGANIZATION.” The 
relative simplicity of the current DECAIDS knowledge base 
lends itself to the use of this single context. In more 
complex subject domains, it may become necessary to organize 
system attributes into multiple contexts. For example, 

EMYCIN uses PERSON (the root context) , CULTURES (the results 
of infectious cultures) , and ORGANISMS (the types of organisms 
obtained from cultures and treated which is to be prescribed) 
[Davis, 1977]. System designers must decide a priori , based 
upon system complexity, how parameters are to be organized 
into contexts. It is noteworthy to mention that with proper 
organization, even relatively large systems can be frequently 
organized under one context. However, if multiple contexts 
are used, they must be arranged in a context tree which 
allows the production rules to refer to parameters of more 
than one related context. This is accomplished with the 
context properties ASSOCWITH and OFFSPRING. These properties 
are lists of ancestors and descendant context types, respec- 
tively. 

Contexts are declared in a manner similar to that 
used to declare parameters. (This is true because contexts 
are also parameters.) These specific procedures are dis- 
cussed in the following section. 

The primary properties which must be declared for 
contexts are: MAINPROPS, TRANS, PROPTYPE, TYPE, RULETYPE, 
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and GOALS. Other properties, included as Appendix D, are 
necessary for describing systems which are more complex 
than DECAIDS. These names are system names and are explained 
as follows. 

MAINPROPS - These are the main parameters which 
describe a context. These parameters are declared as a list 
and are used to "trace” or define the context. The consul- 
tation session includes an interactive phase where these 
MAINPROPS are asked of the user. User responses will invoke 

f/ 

the appropriate production rules to produce the consultation 
recommendations. The order in which these parameters are 
listed in the property of MAINPROPS assists in providing a 
more logical or "coherent” consultation for the user. 

TRANS - This property is the literal translation of 
the context (or parameter) . This definition describes how 
that context will be translated in the program. In DECAIDS, 
the TRANS of the context ORGANIZATION is "the organization." 

PROPTYPE - This property is used by the system to 
identify to which context a particular parameter belongs. 
DECAIDS contains one PROPTYPE for ORGANIZATION, PROP-ORG. 

TYPE - This property is the name used to identify 
contexts. For example, successive consultations involving 
the context ORGANIZATION will be titled "ORGANIZATION 1, 
ORGANIZATION 2, ORGANIZATION. . .". 

RULETYPE - This is a list of the rules which must be 
searched in order to find a particular parameter. ORGANIZATION 
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currently has only one ruletype, ORGRULES , which contains 
all rules to determine the goal-parameters. This name was 
chosen to stand for ’’organization rules.” 

GOALS - This is a list of goal -parameters which are 
applicable to the context. More than one goal is allowable. 
This allows for the more complex systems to be represented 
by single contexts. Current goal-parameters for ORGANIZATION 
are DECAIDS, UNKSTRUC, and FORSTRUC. 

2 . Parame ters 

Parameters are defined as attributes which describe 
a given context. In the knowledge base, ’’object-attribute- 
value” triple, parameters are the attributes. These attri- 
butes may be thought of as questions to be asked (of the user 
or the system) that describe the context. For example, the 
system designer will ask the following type of questions, 

”Is the ’parameter’ of the ’context’ a ’value’?” The values 
correspond to appropriate answers to the designer's questions. 
These are pre-specif ied (if appropriate) by declaring them 
in the EXPECT property of the particular parameter and are 
explained later in this section. 

The use of parameters in production rules has been 
discussed. Parameters are contained in the various lists 
with names of the form PROP- type. This form indicates a 
prompt which the user will answer. These lists are further 
collected into either PROPGROUPS or AUXPROPGROUPS . PROP- 
GROUPS initially contain the reserved work PROP-VAL, which 
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is the PROPTYPE for contexts, and eventually contain each 
parameter group declared in the context's PROPTYPE property. 
(Keep in mind that contexts are declared in the same manner 
as parameters.) AUXPROPGROUPS are lists of auxiliary 
parameters which serve varying purposes. The most useful of 
these purposes is defining a RULEGROUP. A RULEGROUP will 
be explained in the following section. 

The most frequently used parameter properties in 
the DECAIDS system are: TRANS, PROMPT, EXPECT, REPROMPT, and 

LAB DATA. 

TRANS - This is the literal translation of the 
parameter. TRANS is declared in the same manner as contexts. 

PROMPT - This property is the natural language 
text question which is asked of the user concerning each 
parameter. Care should be taken when composing prompts 
so that the consultation dialogue makes sense to the user. 

(The context's MAINPROPS property can be used to assist in 
making the consultation flow smoothly and logically. 

Parameter PROMPTS are asked in the same order the parameters 
are listed in the MAINPROPS.) 

EXPECT - These are the accepted or "expected" 
responses to the PROMPTS. The specific values may be 
supplied by either the system designer or user. In order 
to specify that anything is an appropriate answer, the word 
"ANY" should be entered as the EXPECT value of that parameter. 
If a parameter has a PROMPT, it must also have an EXPECT 
value . 
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REPROMPT - These are additional natural language 



text statements which are used to further explain the 
question asked by parameter PROMPTS. They are of great value 
to the designer and user because they can remove ambiguity 
concerning PROMPT meanings. They automatically list the 
accepted responses which the system will recognize. This 
property is invoked when the user responds with a question 
mark when asked a parameter PROMPT. 

LABDATA - This property is a system key that indi- 
cates that the user will provide a value for that parameter. 
This is done by entering ”T" as the value for LABDATA. 

An example of these various properties is provided 



for the following 


DECAIDS parameter; 


FORMAL : 


(Parameter name) 


TRANS : 


(The organization's structure) 


PROMPT : 


(The formal structure of the organization 
can be defined as either line, staff, 
matrix, functional, or not available. If 
further explanation of these terms is need- 
ed, type a question mark. What is the 
organization's formal structure?" 


EXPECT : 


(Line, Staff, Functional, Matrix, Not 
Available) 


LABDATA: 


T 


REPROMPT : 


(Line-emphasizes direct chains of authority 
and unity of command. Staff - includes an 
informational and advisory staff to assist 
and guide operational personnel. Functional 
arranges personnel by functional activity 
such as logistics, communications, etc. 
Matrix-draws personnel from across depart- 
mental lines.) 
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3 . Rulegroups 



All rules must be assigned to groups called rule- 
groups prior to being declared (entered on the system). 

If no rulegroup is defined, the rules will not compile. 
Rulegroups are determined by the type(s) of contexts to which 
a rule may apply. Generally, a rule is applicable to the 
lowest context in the tree whose parameters appear in its 
PREMISE or ACTION. The group for the rule must be in the 
RULETYPES property of the applicable context type(s). In 
most cases, the RULETYPES property will be a list of a single 
group. All rulegroups are members of the parameter group 
called ALLNAMES. The use of ALLNAI4ES is covered in the 
GETPARMS section of this chapter. Before entering rules, 
it is necessary to define and initialize all rulegroups which 
are named "typeRULES . ” The procedure for accomplishing this 
is to type "SET (typeRULES NIL)" and then define the group 
by the GETPARMS routine. (The word type in lower case 
letters refers to the specific type used. In DECAIDS, the 
rulegroup is called ORGRULES. This stands for organization 
rules . ) 

Rulegroups have the following properties: 

CONTEXT - This is the list to which rules of this 
type apply. 

SVAL - This property tells how to translate the 
reserved word "CNTXT" in rules of this type. 

CTRANS - This is a phase in English (a translation) 
describing what context types the rules apply to. This 
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translation fills in the blank in the EMYCIN system phrase, 



"this rule applies to . " This explanation precedes 

actual rules when rules are actually printed by the 
PRINTRULES routine. The use of this routine is explained 
in this next section of this chapter, 

D. GETTING STARTED 

1 . Accessing the ARPANET 

The DECAIDS system currently resides on a computer 
at the Information Sciences Institute of the University of 
Southern California. Access to the system may be accomplished 
through the ARPANET. The different uses and further back- 
ground material on the ARPANET are not contained in this 
paper. The specific procedures used to access the DECAIDS 
program on the ARPANET are contained in Appendices F and G. 

2. GETPARMS 

The EMYCIN program contains a routine, GETPARMS, 
which is used to declare all contexts, parameters, and rule 
groups. After logging onto the ARPANET and entering the 
EMYCIN executive file, EMYCIN.EXE, (as discussed in Appendix F) 
the procedures outlined in Appendix G are used to enter, 
edit, or delete parameters. 

The most frequently used parameter properties used 
in DECAIDS are: TRANS, EXPECT, PROMPT, LABDATA, and 

REPROMPT , as discussed previously. The most important of 
these properties is PROMPT as it "prompts" the natural 

language question which will be asked of the user concerning 
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a particular parameter. The PROMPT should be written in 
such a manner as to present a logical dialogue to the user. 
The LABDATA property is a system key which indicates that 
the appropriate value of a parameter must be obtained 
from the user. 

3. GETRULES 

The GETRULES routine is used to declare system rules 
after the various parameters have been entered. These system 
rules are written to arrive at a final goal and thereby 
conclude the value of a parameter. Appendix G contains the 
specific procedures to be followed when using GETRULES. 

Rules are entered in two parts, PREMISE and 
ACTION. Following the final parentheses in the ACTION 
clause, the rule is checked for syntactic validity and an 
error message is returned if an error is detected. If the 
subject of the rule cannot be deduced, the user is asked to 
confirm the rule group. The proper response is "Y” (yes] 
if the offered rulegroup is correct or the rule group is 
entered. 

There is a useful feature that may be used in con- 
junction with either GETRULES or GETPARMS. If, during the 
course of entering rules or parameters, the user discovers 
the necessity of returning to the other routine, he may do 
so by typing "RULES" (in GETPARMS) or "PARAMETER" (in 
GETRULES) . This facilitates writing a set of parameters 
and then calling GETRULES to declare the relevant rules. 
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The recommended format for entering rules is the 
INTERLISP syntax. A "terse" English form is available but 
requires much more typing. Additionally, in preparing the 
rules via the INTERLISP syntax, the concept of writing a 
set of rules to produce backward- chaining (which drives the 
direction of a consultation) becomes more apparent. Most 
of the premise clauses will be calls to the predicate 
functions SAME, NOTSAME , or KNOWN. These can be written as: 

INTERLISP: terse meaning: 

(SAME CNTXT parm value) parm = value 

or 

(NOTSAME CNTXT parm value) parm / value 
The following example is from DECAIDS: 

(SAME CNTXT STRESS LOW) STRESS = LOW 

Similarly, the numeric predicates can be entered as: 
INTERLISP: 

GREATERP* (VALl CNTXT parm) number) 

Terse meaning: 
parm value = number 

No numeric predicate functions are currently used in DECAIDS. 

ACTION statements will contain functions that con- 
clude about one or more of the context-parameter-value 
triples. A certainty factor (cf) for the triple is specified 
in the rule's ACTION. This certainty factor will be modified 
by the certainty of the rule's PREMISE. The function "$AND" 
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sets the reserved word TALLY to the certainty o£ the 
PREMISE, defined to be the minimum of the values returned 
by evaluating the PREMISE clauses (only SAME and THOUGHTNOT 
return numbers). The conclusion may be written as; 

(CONCLUDE CNTXT parm value TALLY cf) 
parm = value (cf) 

The following example is from DECAIDS ; 

(CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 
type system = real-time with a certainty of 0.8 

The certainty factors are actually written in the range 
-1000 to 1000. This range represents the -1 to 1 mentioned 
earlier. The system writer should use the numbers in the 
preceding range in a call to CONCLUDE or other ACTION 
functions . 

The function DO-ALL is used to conclude about the 
several parameters which comprise any multi-valued parameter, 
such as DECAIDS. Once a goal -parameter has been traced, 
the rule calling for PRINTCONCLUSIONS will be evaluated true 
and an output statement will be generated. (See rule 001 in 
Appendix A. ) 

4 . Declaring the Treeroot and the RULEGROUP Type 

Once it has been decided what the system objective is, 
the context tree is designed and filled in. It is necessary 
to make the following system declaration. From the EMYCIN . 
EXE, (not GETPARMS or GETRULES) the "SET” command is used 
to define the context tree root in the following format: 
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_SET( TREEROOT rootcontxt) 

_SETQ(ROOTTYPE (GETP ' roo tcontext ' TYPE) ) . 

An example of the procedure using a DECAIDS example follows: 

_SET(TREEROOT ORGANIZATION) 

_SETQ(ROOTTYPE (GETP 'ORGANIZATION 'TYPE) ) . 

The is the EMYCIN.EXE prompt. Upper or lower case letters 

may be used to set the rootcontext name. This function 
should be performed along with "SETting" the RULEGROUP: 

_SET (rule type) 

In DECAIDS: 

_SET(ORGRULES) . 

The preceding examples contain capital letters because 
capitals were used throughout the DECAIDS program. 

In order to save items such as the treeroot and 
rulegroup declarations, it is necessary to edit the 
CHANGESCOMS files. This file is a list delineating what 
should be stored on the CHANGES current program file. With 
the command "MF CHANGES," the editions, additions and 
deletions to GETPARMS and GETRULES are saved. However, the 
following procedure must be used to save the treeroot and 
rulegroup. (The is the EMYCIN prompt and the is the 

INTERLISP prompt.) The following is an example from DECAIDS: 
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EV CHANGESSCOMS 



(This command edits the 
variables that follow.) 



*(-l TREEROOT) 



C’-l” means insert the 
following before the first 
element in the list.) 



*SET (TREEROOT ORGANIZATION) 

*SETQ(ROOTTYPE (GETP ’ORGANIZATION 'TYPE) ) 
*SET(ORGRULES) 



*OK 



(This exits the editor and 
the file must be saved with 
ME CHANGES.) 



5 . Saving Changes to Rules and Parameters and Deleting 

Changes 

Each update, addition, deletion, or edit to the 
system knowledge base is referred to as a CHANGE. Each CHANGE 
requires the complete recopying of the entire program. The 
command used to save these changes is "MF CHANGES." A new 
file is created when the user enters the system each time. 

This file is comprised of all previous information that has 
been entered plus the new entries to the knowledge base. 
Accordingly, there is no need to keep multiple copies of 
the previous CHANGES after creating a file of new CHANGES. 
These "old" copies may be deleted by using the command, 

"DEL CHANGES .. (number to be deleted)." If no number is 
specified, the lowest number version (or oldest) will be 
deleted. (During the login procedures, the entire file 
status is presented to the user. The CHANGES file will 
indicate exactly what number the user currently has in use.) 
Occasional naming conflicts have occurred with the operating 
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systems, TENEX and TOPS-20, resulting in unwanted change 
deletions. It is therefore recommended that the user 
maintain at least two or three changes as ''insurance” 
against losing everything that has been entered. 

6, Loading CHANGES 

In order to run a consultation, it is necessary to 
concatenate the knowledge base with EMYCIN.EXE. This is done 
by the following command, "LOADEM CHANGES.” The file which 
is currently in use has this command included in the executive 
login procedures and therefore does not have to be entered by 
the user. 

7 . Displaying Parameters 

The following PRINTPARMS command should be used to 
display all, or part of the parameters entered in the know- 
ledge base: 

”_PRINTPARMS (parm sort .by . group linelength file) 

where parms may be a list of parameters, a list of parameter 
groups, a single parameter group, or NIL meaning all param- 
eters. The term "sort . by . group" is T or NIL. T means that 
an alphabetical index is printed first, showing which group 
each parameter belongs in. NIL indicates that the parameters 
are listed in alphabetical order regardless of the group to 
which they belong. Linelength is the length of the line to 
be used, i.e., 72, 78, or 80 spaces. File is the name of 
the file in which to write the information. If T is used. 
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lis 




the parameters will be written to the terminal. The 
PRINTPARMS command may be used within the DRIBBLE command 
(which is explained in Section 9 of this chapter) to write 
the parameters into a separate file. An example of this 
command follows: 

_PRINTPARMS(NIL T 72 T) . 

8 . Displaying Rules 

The procedure for displaying knowledge base rules is 
similar to the PRINTPARMS command. The command is: 

_(PRINTRULES rules mode). 

In this command, rules is a list of rules, a rule group, 
and mode indicates how the rules are to be printed. Mode 
includes these options: 

B - both in English and INTERLISP 

E - in English 

L - in INTERLISP 

J - for justification which permits inclusion 
of author's name. 

9 . Creating a File in the EMYCIN.EXE 

In order to create a file of the knowledge base 
contents, the following sequence of commands is used: 
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_DRIBBLE ( filename) where the filename is of the user's 

choice and DRIBBLE opens a type- 
script for the filename. 

_PRINTPARMS (or PRINTRULES) 

_DRIBBLE The last DRIBBLE command closes the file. 

10 . Running a Consultation 

Appendix F contains the specific procedures that 
are required to run a consultation. This section contains 
supplementary information that is not found in that appendix. 

The following special options are available when 
running a consultation, "FT 1, 2, 3, 4, or carriage return 
"(no options)." FT stands for fault trace. The numbers that 
follow FT indicate the level of the "trace" desired with 1 
being the lowest and 4 being the highest degree of fault, 
or rule, tracing. Fault trace 4 (FT4) will present each 
rule number as it is being sought, indicate that the 
FINDOUT routine is tracing the appropriate parameter, and 
complete with the FINISHED routine when a rule has been 
completely traced. Once the rule is evaluated as true, this 
is indicated by a message "RULE (#) SUCCEEDED." 

At the other end of the scale, FT 1 will show those 
rules which have succeeded and then display their ACTION 
statements . 

The user can request the following special features 
by entering one or more of the following options with spaces 
and ending with a carriage return: 



74 



I - 


requests instructions to be printed. 


OLD - 


consider a previously-saved case (number(s) 
will be requested). 


SAVE - 


create and save file(s) for cases discussed 
in this consultation. 


NOPR - 


do not print out old questions and answers 
when running old cases. 


SUMMARY - 


summarize old session data, rather than 
printing out each question and answer. 


UPDATE - 


update old session with new information 


TER - 


enter terse mode. 


TAB - 


tabular entry mode . 


TS - 


write out a typescript file of consultation. 


N - 


(a number) reconsider previously saved case n 


QA - 


enter the question/answer module immediately 
skipping the consultation (currently turned 
off in EMYCIN) . The terms "case" and 
"patient" remain from the original EMYCIN 
system referring to a medical consultation. 



The following instructions are printed if the user 
responds '*Y'' when asked if instructions are desired: 

Please answer the following questions, terminating 
each response with RETURN (CR) . To correct typing errors, 
use the DELETE key to delete characters, (ctrl)W to 
delete a word and (ctrl) L to delete the whole line. 

If you are not certain of your answer, you may modify 
the response by inserting a certainty factor (a number from 
1 to 10) in parentheses after your response. Absolute 
certainty (10) is assumed for every unmodified answer. It 
is likely that some of the following questions cannot be 
answered with certainty. You may change an answer to a 
previous question in two ways. If the program is waiting 
for a response from you (that is, has typed ”**’'), enter 
CHANGE followed by the number (s) of the question(s) whose 
answers will be altered. You may also change a previous 
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answer at any time (even when the program is not waiting 
for a response from you) by typing (ctrl)F (Fix) , which 
will cause the program to interrupt its compilation and 
ask what you want to change. If the response to (ctrl)F 
is not immediate, try typing the RETURN key in addition.) 
Try to avoid going back because the process requires 
reconsidering the case from the beginning and therefore 
may be slow. Note that you may also enter UNK (for 
unknown) . If you do not know the answer to a question, 

? if you wish to see a more precise definition of the 
question or some examples of recognized responses, ?? 
if you want to see all recognized responses, the word 
RULE if you would like to see the decision rule which 
has generated the questions being asked, the word WHY 
if you would like to see a more detailed explanation of 
the question, or the letters QA if you would like to 
interrupt the consultation in order to ask questions 
regarding the decision made so far in the consultation. 

If you are ever puzzled about what options are available 
to you during a consultation, enter the word HELP and a 
list of options will be listed for you. 

Sample response (user input follows "**”) 

Does the patient have a risk factor 
for tuberculosis? 

One or more of the following are considered 
risk factors for TB : A) Positive PPD (5TU) , 

B) History of close contact with a person 
having active TB , C) Household member with 
a past history of active TB , D) Chest x-ray 
showing apical scarring, E) Granulomas 
seen on biopsy of any organ tissue. 

Expected responses are: YES NO 

Enter HELP for user options. 

** YES 



SUMMARY ; 

(Type Ctrl-0 to abort printout) 

UNK - answer not known 

? - rephrases the question and gives examples 

of recognized responses 

?? - prints a list of all recognized responses 

RULE - prints the current decision rule 

QA - program enters question-answer mode 

CHANGE - go back and re-request answer to question 
number # performance. Your comments will be 
forwarded to those in charge of the MYCIN 
program. 

WHY - gives high-level explanation of the current 
reasoning chain that provoked this question. 

HOW # - explain HOW the system will achieve a goal 

referred to by number # in a previous explanation. 
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EXPLAIN - provides a more detailed explanation of a 
previous answer given by a WHY command. 

FORGET - resets the explanation of the reasoning 
chain back to the lowest level, as if you 
never used the WHY/EXPLAIN commands. 

STOP - halts the program, saving the current case 
on a disk file, retrievable at a later date. 

HELP - prints this list. [Scott, 1979]. 

Once the user has answered the system queries con- 
cerning instructions and options, the consultation will 
begin. When a goal -parameter is found, the conclusion rule, 
currently called PRINTCONCLUSIONS , will be triggered and the 
consultation ended. An example consultation is contained 
in Appendix C. Fault trace 4 (FT 4) was selected for this 
sample consultation. 

11. IxNTERLISP EDITOR 



Chapter Nine of the INTERLISP Reference Manual fully 
describes the editor used with the DECAIDS program [Teitelman, 
1974]. The editor is entered from the EMYCIN.EXE by typing 
"E” and may be reached from GETPARMS or GETRULES in order 
to change parameters or rules. The following is a short 
list of the most often used editor commands: 

n - (n is a positive integer) move to the 

nth element of the list where the element 
is a parenthetical expression. 

p - print the current expression, used with 

GETPARMS or GETRULES. 



-n - move to the nth element from the end. 

(-n X) - insert X after the current element. 

B X - insert X before the current expression. 
: - delete the current expression. 
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: X - replace the current expression with X. 

OK - ends editing. 

The "MF CHANGES" command is used to save all the editing which 
has been done . 

1 2 . Miscellaneous DECAIDS Notes 

The following notes are included as information that 
applies to the DECAIDS program. 

The INTERLISP compiler compiles upper and lower case 
letters differently. Either may be used to fill a knowledge 
base. For example, "DECAIDS" will compile differently than 
"decaids" and subsequent use in rules will result in an error 
message stating that there are not rules to conclude one or 
the other. Because of this problem, DECAIDS was entered on 
the machine in all capital letters. 

The system permits a consultation user to respond 
with "unknown" to a request for information which is not 
known to the user. This "UNK" means that the certainty factor 
for the rule should be set to less than .2, the system's 
arbitrary limit for acceptable knowledge about a parameter. 
Therefore, if the system writer desires to provide some other 
certainty factor about an unknown condition, he must offer a 
substitute response for "UNK" in the expect values. 
"NOTAVAILABLE" was the choice used in DECAIDS. 

Rule 035 is the print statement for the goal- 
parameter UNKSTRUC. If UNKSTRUC was not known, then a 
recommendation was made about the informal organization 
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structure to be recommended. If UNKSTRUC was known, no 
output was necessary. To "turn off" the output, even though 
UNKSTRUC had been traced, the HEADER in the PRINTCONCLUS IONS 
function (Appendix E) was left at NIL. 

In rule 034, a parameter in the rule PREMISE is also 
used in the ACTION. In the parameter's USED-BY property (a 
system property not used by the designer) the note 
SREFMARK 34 appears. This means that the parameter is in 
the PREMISE and ACTION of rule 034 and is a system flag to 
prevent various search and circularity problems. 

The parameter property REPROMPT is used to locate 
the text presented to the consultation user if and when he 
responds with a "?" for an expected parameter value. The 
system designer includes further explanation of expected 
values or the parameter definition in the REPROMPT. 

The "WHY" response to a question rather than an 
allowed expected value produces an explanation of the 
current reasoning chain that provoked the current question. 
For the "WHY" question to work, the system writer must 
previously have used the LISP SET command to set the value 
of FINDBESTPARM. This value is used to an EMYCIN to provide 
text to explain the reasoning chain. 

If intermediate values are desired to be known, 
not necessarily those of the goal-parameters, the system 
writer need only write a rule to "PRINTCONCLUSION" for 
that parameter. 
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VIII. CONCLUSION 



It was the purpose of this thesis to demonstrate the 
implementation of a particular domain of information with 
the Artificial Intelligence system known as EMYCIN. The 
demonstration illustrates that even semi-structured and 
subjective domains can be studied using AI technology. 

The domain chosen for this paper was that of managerial 
decision aiding. This particular subject contains many 
intuitive thought processes. The uncertainties and impre- 
ciseness of intuition lends itself to one of the goals of 
Artificial Intelligence which is the capability of producing 
relevant, acceptable assertions in the light of incomplete 
and uncertain information. 

Recommendations are offered concerning possible exten- 
sion of the current, single context knowledge base to a 
multiple context tree. Also, the motivations for further AI 
work are established and a summary of the research conducted 
and accomplishments are presented. The motivations mentioned 
represent the current interest for continuing Artificial 
Intelligence research and development. 

A. EXTENDING THE DECAIDS CONTEXT TREE 

The current domain of information is described by a 
single context and related parameters. It is intended to 
be a prototype domain for a decision aiding support system 
and an example of how to structure a knowledge base. It is 
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expected that the knowledge base will be extended to include 
a more complex context tree supporting a far more thorough 
treatise of the decision aiding support process. The 
following information is directed toward the individual who 
will extend the current knowledge base. 

Prior to doing any coding or entering of any rules or 
parameters, it is strongly advised (cf 1.0) that the system 
goal(s) be explicitly defined. This means not only deciding 
that the system is to provide some form of advice but, more 
specifically, to write out the natural (i.e., English) 
language questions which will be used to trace parameter 
values. Entering rules and parameters into the DECAIDS 
knowledge base is not unlike any other high- level - language 
coding where a flowchart of operations and data manipulation 
are appropriate. A system designer is reminded that the 
primary emphasis for extending a knowledge base is a co.n- 
sistent line of questions to be asked in order to trace 
parameter values. Eliminating or ignoring the requirement 
to specify the questions to be asked can only lead to 
confusion . 

When to define a context or multiple contexts may present 
the system designer with some confusion. It is recommended 
that the designer review the notes on backward-chaining and 
the concept of inferences. This information (Chapter VII) 
will provide the necessary background for constructing 
rules which terminate in the determination of values for 
parameters . 
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Most often a single context will suffice for a small to 
medium size knowledge base. However, to fully describe the 
management decision aiding characteristics about some subject 
(i.e., electronic warfare, major procurement systems, etc.) 
may require a more complete context tree. The subjects 
that become contexts are those that cover areas of informa- 
tion which will always, or nearly always, be used to define 
the value of the root, goal-parameters. The infectious blood 
disease domain of MYCIN, for example, is described by the 
following contexts: 

PATIENT 

CULTURE 

ORGANISM 

Each of these contexts has multiple parameters leading to 
the goal-parameter (s) values. The management domain might 
include contexts such as : 



DECISION 

, ^ ^ , 

TECHNOLOGY ENVIRONMENT TASK STRUCTURE 



ADMINISTRATIVE TACTICAL 

or : 

DECISION 

ELECTRONIC WARFARE ASW AIRBORNE . 
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The selection of contexts is strictly the systems designer's 
choice. The system is best kept as uncomplicated as the 
subject will permit. Rules and parameters will be grouped 
by the RULEGROUP and PROPGROUP properties, respectively, 
and selected by the rule interpreter/monitor for use in the 
program. The designer's responsibility is to design a logical 
set of backward -chaining rules, to define all rules and 
parameters, and to structure the context tree. 

B. ARTIFICIAL INTELLIGENCE MOTIVATIONS 

The following example and the motivation descriptions 
for AI work are offered to stimulate further developments 
in the field. 

Artificial Intelligence programs may be described as 
containing powerful search algorithms (control strategies) 
operating upon data-bases in order to efficiently produce 
relevant logical inferences. This description mentions 
algorithms, necessary to all computer work, and the use of 
data but the energy required to accurately represent data in 
a "real world" manner must also be emphasized [Sacerdoti, 

1979] . Thus the two key issues in AI work are control and 
data representation. 

Representation and control become important when going 
beyond toy systems and proceeding into more useful programs. 

A chess game is used as an example. The game can be 
described as the use of a database consisting of a number 
of legal moves. This description may describe the game but 
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does not tell one how to build a better chess program or how 
to play better chess. 

Therefore, two major motivations are established for 
Artificial Intelligence work. First, analogous to building 
a better chess program, there is the engineering motivation 
to make computers more useful by making them "smarter” -- 
endowing them with common sense, giving them access to a 
full sensory world, and enabling them to understand humans 
on the human's terms. Secondly, analogous to playing better 
chess, there is the scientific motivation to study the 
nature of knowledge and the mechanisms of intelligent 
behavior independent of their embodiment in man or machine. 

As with any computing device or concept. Artificial Intelli- 
gence work is designed to extend man’s capabilities permitting 
him to perform more and, hopefully, better accomplishments. 

C. STUDY AREAS 

Of the time expended to complete this thesis, the major 
portion (approximately three and one half months) was occu- 
pied by learning the EMYCIN system and the supportive concepts 
and programs. This included a study of predicate calculus 
as it applies to Artificial Intelligence, the study of pro- 
duction rules, the use of backward -chaining in a goal-seeking 
system, an overview of the LISP programming language and its 
functions, and the use of the ARPANET system which permitted 
the transfer of the EMYCIN file from Stanford University 
to the University of Southern California. The transfer of 
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the file, and the resulting, successful portability was 
facilitated by both schools using DEC-1090 computers with 
the TOPS- 20 operating system. Additionally, familiarity 
with user features of the TENEX operating system, the HERMES 
automatic message handling system, the Experimental Editor 
(XED) , and debugging procedures used with the INTERLISP 
programming language were also required to complete this 
thesis. Continued work in AI , in particular the DECAIDS program 
using the ARPANET, will require a review of the areas of study 
listed. 

In order to successfully complete an AI project, such as 
DECAIDS, additional time must be scheduled for deriving the 
data to be used in a knowledge base. Coincident to the 
previous list of study areas was the effort required to collect 
the required expert knowledge. The modeling of a management 
system required approximately one and one half month's time. 

The management modeling process continued into what was 
informally referred to as the use of the EMYCIN "production 
rule language." 

The lack of user oriented documentation concerning the 
use of the EMYCIN production rule language caused some delays 
in completing the knowledge base and producing a running 
program. While an "EMYCIN.DOC" documentation file has been 
prepared by the Stanford AI group, it has been written more 
as a set of very complete notes for the Stanford group 
rather than as a set of user oriented instructions. Problems 
in getting the DECAIDS program on-line were resolved by 
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ARPANET messages, telephone calls, and personal visits to 
the Stanford group and by reference to the INTERLISP 
manual. This interaction between NPS and Stanford did assist 
the efforts of the AI people at Stanford in extending the 
user information contained in the documentation for EMYCIN. 

Acknowledgement for a vast amount of information and 
selfless assistance in sharing her knowledge of production 
rules and their application to AI is given to Miss Carlisle 
Scott of the Stanford University Computer Science Department. 
Recognition is also given to Dr. E. Fiegenbaum (Chairman of 
the Computer Science Department at Stanford University) for 
his assistance, and to Dr. Nils J. Nilsson (Stanford Research 
International, Menlo Park, California) for permission to 
use material from his forthcoming book. Artificial Intelligence 
A Framework. 
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APPENDIX A 

DECAIDS PRODUCTION RULES 



RULEOOl 



CThis rule is def ini t i onal f applies to ORGANIZATION r and is tried 
when inf ormat ion is received about THE DECISION!] 

IfJ An attempt has been made to deduce THE DECISION 
Then: Display THE DECISION 



premise: <$AND (ONCEKNOWN CNTXT DECAIDS T)) 
action: (PRINTCONCLUSIONS CNTXT DECAIDS T) 

CORGRULES/antecedent J 



RULE002 



CThis rule appli':s to ORGANIZATION f and is tried in order to find out 
about THE DECISIONJ 

If: 1) THE TYPE OF SYSTEM RECOMMENDED TO BE USED is known r 

2) THETYPE OF OUTPUT DEVICE TO BE USED is known f 

3) THE RECOMMENDED INSTALLATION TO BE USED is knownr and 

A) THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is 
known 

Then: It is definite (1*0) that the following is one of THE 

decision: use the following type SYSTEM <typsys> THE 
OUTPUT SHOULD BE DISPLAYED ON <outPut> THE MANNER OF 
INSTALLATION SHOULD DE <install> AND THE RECOMMEND ATI ON 
FOR TRAINING AND ASSISTANCE IS <trsi> ♦ 



premise: ($and (known cntxt typsys) 

(KNOWN CNTXT OUTPUT) 

(KNOWN CNTXT INSTALL) 

(KNOWN CNTXT TRG ) ) 

action: (CONCLUDETEXT cntxt DECAIDS (TEXT NIL 

•USE THE FOLLOWING TYPE SYSTEM’ 

(VALl CNTXT TYPSYS) 

•THE OUTPUT SHOULD BE DISPLAYED ON* 
(VALl CNTXT OUTPUT) 



•THE MANNER OF INSTALLATION SHOULD BE* 
(VALl CNTXT INSTALL) 

•AND THE RECOMMENDATION FOR TRAINING AND ASSISTANCE IS* 

(VALl CNTXT TRG) 

• . • ) 

TALLY 1000) 
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RULE003 



CThis rule applies to ORGANIZATION f and is tried in order to f ind out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDf THETYPE OF 
OUTPUT DEUICE TO BE USEDf THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIREDJ 

If: THE ORGANIZATION'S STRUCTURE is centralized 

Then: 1) There is stronsJlu su^isestive evidence (*8) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is real-timer 

2) There is stroni^ly susJaestive evidence (♦S) that THETYPE 
OF OUTPUT DEVICE TO BE USED is individual-terminals r 

3) There is stronf^ly su^Sestive evidence (»8) that Tf^E 
RECOMMENDED INSTALLATION TO BE USED is pyramidalr and 

4) There is strons^ly su£l5iestive evidence (*8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is do- 
no t -hi re- special ists 



premise: ($AND (same CNTXT informal CENTRALIZED)) 

action: (DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUTPUT INDI VIDUAL-TERMINALS TALLY 
800) 

(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 800) 
(CONCLUDE CNTXT TRG DO-NOT-HIRE-SPECIALISTS TALLY 
800) ) 

CORGRULESJ 



RULE004 



CThis rule applies to ORGANIZATION r and is tried in order to Tind o'jt 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDr THETYPE OF 
OUTPUT DEVICE TO BE USEDr THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED3 



If: 

Then 



THE LEADER'S LEVEL OF TRAINING is skilled 

1) There is strongly su^destive evidence (*8) that THE TYPE 
OF SYSTEM RECOMMENDED TO BE USED is real -timer 

2*) Hi re-specialists f 

3) Thiere is strondly sudsestive evidence (*8) that THETYPE 
OF OUTPUT DEVICE TO BE USED is individual-terminals r 

4) There is strondly suddestive evidence (.8) that THE 
RECOMMENDED INSTALLATION TO BE USED is pyramidalr aj.d 

5) There is strondly suddestive evidence (*8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is do- 
no t -hi re-speci al ists 



premise: ($AND (same CNTXT leader-training SKILLED)) 

action: (DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 

HIRE-SPECIALISTS 

(CONCLUDE CNTXT OUTPUT IND I VIDUAL-TERM INALS TALLY 
800) 

(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 800) 
(CONCLUDE CNTXT TRG DO-NOT-HIRE-SPECIALISTS TALLY 
800) ) 

CORGRULEST 
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RULE005 



CThis rule applies to ORGANIZATION r and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USED. THETYPE OF 
OUTPUT DEVICE TO BE USEDf THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED^ 

If: THE LEADER'S LEVEL OF TRAINING is known 

Then: 1) There is sui^i^estive evidence (*5) that THE TYPE OF SYSTEM 

RECOMMENDED TO BE USED is real-timef 

2) There is su^^estive evidence (*5) that THETYPE OF OUTPUT 
DEUICE TO BE USED is indi vidual-terminals r 

3) There is su^Sestive evidence i *5) that THE RECOMMENDED 
INSTALLATION TO DE USED is unavailabler and 

4) There is su53^estive evidence (»6) that THE RECOMMENDED 
TRAINING OR ASSISTANCE TO BE ACQUIRED is hi re~spec i a 1 i s t s 



premise: 

action: 



(<^AND (KNOWN CNTXT LEADER~TRA INI NG UNSKILLED)) 

(DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 500) 

(CONCLUDE CNTXT OUTPUT IND I U I DUAL-TERMINALS TALLY 
500) 

(CONCLUDE CNTXT INSTALL UNAVAILABLE TALLY 500) 
(CONCLUDE CNTXT TRG HIRE-SPECIALISTS TALLY 600)) 



CORGRULEST 



RULE006 



CThis rule applies to ORGANIZATION f and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDf THETYPE OF 
OUTPUT DEVICE TO BE USED* THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED^ 

If: THE STAFF'S LEVEL OF TECHNICAL TRAINING is known 

Then: 1) There is su^sestive evidence (*5) that THE TYPE OF SYSTEM 

RECOMMENDED TO BE USED is real-timef 

2) There is sud<2estive evidence (.5) that THETYPE OF OUTPUT 
DEVICE TO BE USED is indi vidual-terminals f 

3) There is strongly sunJ.^estive evidence (*8) that THE 
RECOMMENDED INSTALLATION TO BE USED is pyramidalr and 

4) There is stronslly sud^estive evidence (*8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is do- 
not-hire-specialists 



PREMISE: (iAND (KNOWN CNTXT STFFTRG SKILLED)) 

action: (DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 500) 

(CONCLUDE CNTXT OUTPUT INDI V IDUAL-TERMINALS TALLY 
500) 

(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 800) 
(CONCLUDE CNTXT TRG DO-NOT-HIRE-SPECI ALISTS TALLY 
800) ) 

CORGRULESI 
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RULE007 



CThis rule applies to ORGANIZATION f and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USED r THETYPE OF 
OUTPUT DEVICE TO BE USEDr THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACOUIKEDD 

1ft THE STAFF'S LEUEL OF TECHNICAL TRAINING is unskilled 
ThenJ 1) There is stronslu susslestive evidence <.S) that THE TYPE 
OF SYSTEM RECOMMENDED TO BE USED is real-time^ 

2) There is strondly su^Sestive evidence (*8) that THETYPE 
OF OUTPUT DEVICE TO BE USED is individual-teraiinals r 

3) There is strongly sudSestive evidence (*S) that THE 
RECOMMENDED INSTALLATION TO BE USED is divisional r 'nid 

4) There is strondly sudSestive evidence (»8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is nire- 
special i sts 



premise: 

action: 



($AND (SAME CNTXT STFFTRG UNSKILLED)) 

(DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 



(CONCLUDE CNTXT 
800) 

(CONCLUDE CNTXT 
(CONCLUDE CN rXT 



OUTPUT INDIVIDUAL-TERMINALS TALLY 

INSTALL DIVISIONAL TALLY 800) 

TRG HIRE-SPECIALISTS TALLY 800)) 



CORGRULES: 



RULE008 



CThis rule applies to 0RGANI2AT ION > and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDf THETYPE OF 
OUTPUT DEVICE TO BE USEDf THE RECOMMENDED INSTALLATION TO DE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED.1 

If: THE LEVEL OF THE TASK'S STRESS is hish 

Then: 1) There is strondly suddestive evidence (*8) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is real-timer 

2) There is strondly su5idestive evidence (*3) that THETYPE 
OF OUTPUT DEVICE TC BE USED is indi v idua 1 -te rmina 1 s r 

3) There is strondlu suddestive evidence (*8) that THE 
RECOMMENDED INSTALLATION TO BE USED is pyramidal, and 

4) There is strondly suddestive evidence (*8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is do- 
ne t -hi re-speci a lists 



premise: 

action: 



($AND (SAME CNTXT STRESS HIGH)) 

(DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUTPUT INDI VIDUAL-TERMINALS TALLY 



800) 

(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 800) 
(CONCLUDE CNTXT TRG DO-NOT-HIRE-SPECIALISTS TALLY 
000 ) ) 



CORGRULES: 
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RULE009 



CThis rule applies to ORGANIZATION f and is tried in order to find out 
about THE TYPE OF SYSTEM RECOiMMENDED TO BE USEDr THETYPE OF 
OUTPUT DEVICE TO BE USEDr THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED^ 

If: THE LEVEL OF THE 'TASK'S STRESS is low 

Then: 1) There is suSsfestive evidence (*5) that THE TYPE OF SYSTEM 

RECOMMENDED TO BE USED is real-time f 

2) There is su^^estive evidence (*5) that THETYPE OF OUTPUT 
DEVICE TO BE USED is indi vidual-te rminal s f 

3) There is suSdestive evidence (*S) that THE RECOMMENDED 
INSTALLATION TO BE USED is divisionalr and 

4) There is su^destive evidence (f5) that THE RECOMMENDED 
TRAINING OR ASSISTANCE TO BE ACQUIRED is do-not-hire- 
special ists 



premise: 

action: 



($AND (SAME CNTXT STRESS LOW)) 

(DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 500) 

(CONCLUDE CNTXT OUTPUT INDIVIDUAL-TERMINALS TALLY 



500) 

(CONCLUDE CNTXT INSTALL DIVISIONAL TALLY 500) 
(CONCLUDE CNTXT TRG DO-NOT-HIRE-SPECI ALI STS TALLY 
500) ) 



CORGRULES: 



RULE013 



CThis rule applies to ORGANIZAT ION f and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDr THETYPE OF 
OU IPUT DEVICE TO BE USED 9 THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED! 

If: THE TASK DEFINITION is clear ly-def ined 

Then: 1) There is strondly s«jsdestive evidence (*8) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is real-timcf 

2) There is strondly suddestive evidence (*8) that THETYPE 
OF OUTPUT DEVICE TO BE USED is individual-terminals r 

3) There is strondly suddestive evidence (*8) that THE 
RECOMMENDED INSTALLATION TO BE USED is pyramidal, and 

4) There is strondly suddestive evidence (*8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is do- 
no t-hi re-speci al ists 



premise: ($AND (same CNTXT PROBDEF CLEARLY-DEFINED)) 

action: (DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUTPUT INDI VIDUAL-TERMINALS TALLY 
800) 

(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 800) 
(CONCLUDE CNTXT TRG DO-NOT-HIRE-SPECI ALISTS TALLY 
800) ) 

CORGRULES! 
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RULE014 



CThis rule applies to ORGANIZATION f and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDf THETYPE OF 
OUTPUT DEUICE TO BE USEDr THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIREDJ 

If: THE TASK DEFINITION is ambisiuous 

Then: 1) There is sui^iiiest i ve evidence ( *5) that THE TYPE OF SYSTEM 

RECOMMENDED TO BE USED is real-time^ 

2) There is su^^estive evidence (»5) that THETYPE OF OUTPUT 
DEUICE TO BE USED is individual -terminal s t 

3) There is suSSestive evidence (»5) that THE RECOMMENDED 
INSTALLATION TO BE USED is divisionalr and 

4) There is sussestive evidence (»5) that THE RECOMMENDED 
TRAINING OR ASSISTANCE TO BE ACQUIRED is do-not-hi re- 
special i sts 



premise: 

action: 



($AND (SAME CNTXT PRODDEF AMBIGUOUS)) 

(DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 500) 

(CONCLUDE CNTXT OUTPUT IND I VIDUAL-TERMINALS TALLY 



500) 

(CONCLUDE CNTXT INSTALL DIVISIONAL TALLY 500) 
(CONCLUDE CNTXr TRG DO-NOT-HIRE-SPECIALISTS TALLY 
500) ) 



CORGRULESD 



RULE015 



CThis rule applies to ORGANIZATION f anci is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDr THETYPE OF 
OUTPUT DEVICE Tu BE USEDt THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE FO BE ACQUIRED^ 

If: THE ORGANIZATION'S STRUCTURE is centralized 

Then: 1) There is stronalv suSSestive evidence (*8) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is real-timer 

2) There is strondls sussestive evidence (*8) that THETYPE 
OF OUTPUT DEVICE TO BE USED is indi vidual-terminals r 

3) There is stronsly su^Sestive evidence (»8) that THE 
RECOMMENDED INSTALLATION TO BE USED is puramidalr and 

4) There is strongly suii^sies 1 1 ve evidence (.8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is do- 
not-hi re-special ists 



premise: 

action: 



($AND (SAME CNTXT INFORMAL CENTRALIZED)) 

(DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUTPUT INDIVIDUAL-TERMINALS TALLY 



800) 

(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 800) 
(CONCLUDE CNTXT TRG DO-NOT-HIRE-SPECIALISTS TALLY 
800) ) 



CORGRULESD 
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RULE018 



CThis rule applies to ORGANIZATION r and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDEH TO BE USED. THETYPE OF 
OUTPUT DEUICE TO BE USED. THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED! 

If: THE ORGANIZATION'.S STRUCTURE is consultative 



Then ♦ 



1) There is stronsily su^fiestive evidence (*8) that THE TYPE 
OF SYSTEM RECOMMENDED TO BE USED is real-time. 

2> There is stron^l^# suSdestive evidence ( *8) that THETYPE 
OF OUTPUT DEUICE fO BE USED is indi vidual-terminals . 

3) There is stronslu su5^i:ies 1 1 ve evidence (*8) that THE 
RECOMMENDED INSTALLATION TO BE USED is divisional, and 

4) There is sui^sestive evidence (*0) that THE RECOMMENDED 
TRAINING OR ASSISTANCE TO BE ACQUIRED is do-not-hire- 
special ists 



premise: 

action: 



($AND (SAME CNTXT INFORMAL CONSULTA I I UE ) ) 

(DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUIPUT INDIUIDUAL-TERMINALS TALLY 



800) 

(CONCLUDE CNTXT INSTALL DIVISIONAL TALLY SCO) 
(CONCLUDE CNTXT IRG DO-NO T-HIRE-SPEC I ALISTS TALLY 
500) ) 



CORGRULES! 



RULE019 



CThis rule applies to ORGANIZATION . and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USED. THETYPE OF 
OUTPUT DEVICE TO BE USED. THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED! 

If: THE ORGANIZATION'S STRUCTURE is pa rt i a 1 Is-de 1 ei^ated 

Then: 1) There is stronsil'i^ sui^iiestive evidence (♦S) that THE IfPE 

OF SYSTEM RECOMMENDED TO DE USED is real-time. 

2) There is stron:3ly susJ£^estive evidence (*8) that THETYPE 
OF OUTPUT DEVICE TO BE USED is indi vidual-terminals ^ 

3) There is stronsls suiJ^iestive evidence (♦O) that THE 
RECOMMENDED INSTALLATION TO DE USED is divisional, at.o' 

4) There is sussestive evidence (*5) that THE RECOMMEN(‘E ' 
TRAINING OR ASSISTANCE TO BE ACQUIRED is hi re-SPec j a 1 i st s 



premise: 

action: 



($AND (SAME CNTXT INFORMAL PARTIALLY-DELEGATED)) 



(DO-ALL 



(CONCLUDE 

(CONCLUDE 

(CONCLUDE 

(CONCLUDE 



CNTXT 

CNTXT 

800) 

CNTXT 

CNTXT 



TYPSYS REAL-TIME TALLY 800) 

OUTPUT INDIVIDUAL-TERMINALS TALLY 

INSTALL DIVISIONAL TALLY 800) 

TRG HIRE-SPECIALISTS TALLY 500)) 



CORGRULES: 
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RULE016 



CThis rule applies to ORGANIZATION f and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USED^ THETYPE OF 
OUTPUT DEVICE TO BE USEDf THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED! 

If: THE ORGANIZATION'S STRUCTURE. is line 

Then: 1) There is su.^^estive evidence (»5) that THE TYPE OF SYSTEM 

RECOMMENDED TO BE USED is real-time f 

2) There is su^^estive evidence (*5) that THETYPE OF OUTPUT 
DEVICE TO BE USED is indi vidual-terminal s f 

3) There is susi^estive evidence (.5) that THE RECOMMENDED 
INSTALLATION TO BE USED is puramidalf and 

4) There is su^^estive evidence (*5) that THE RECOMMENDED 
TRAINING OR ASSISTANCE TO BE ACQUIRED is hi re-speci a 1 1 sts 



premise: 

action: 



($AND (SAME CNTXT FORMAL LINE)) 

(DO-ALL (CONCLUDE CNTXT TYFSYS REAL-TIME TALLY 500) 

(CONCLUDE CNTXT OUTPUT INDIVIDUAL -TERMINALS TALLY 
500) 

(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 500) 
(CONCLUDE CNTXT TRG HIRE-SPECIALISTS TALLY 500)) 



C0RGRULES3 



RULE017 



CThis rule applies to ORGANIZATION r and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDf THETYPE OF 
OUTPUT DEVICE TO BE USEDf THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED! 



If: 

Then 



THE ORGANIZATION'S STRUCTURE is THE FORMAL COMPOSITION OF THE 
ORGANIZATION'S STRUCTURE 

1) There is stronsly su^^estive evidence (.8) that THE TYPE 
OF SYSTEM RECOMMENDED TO BE USED is real-timef 

2) There is stronsly sus^estive evidence (*8) that THETYPE 
OF OUTPUT DEVICE TO BE USED is i ndi v i dua 1 -te rm ina 1 s f 

3) There is stronslu suiS^^estive evidence (*8) that THE 
RECOMMENDED INSTALLATION TO BE USED is puramidalf and 

4) There is stron^lu sijd5iestive evidence (*8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is do- 
ne t -hi re-speci al 1 s ts 



premise: ($AND (same CNTXT formal STAFF)) 

action: (DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUTPUT INDIVIDUAL-TERMINALS TALLY 
800) 

(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 800) 
(CONCLUDE CNTXT TRG DO-NOT-HIRE-SPEC I ALISTS TALLY 
800) ) 

C0RGRULE5! 
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RULE022 



CThis rule applies to ORGAN IZATION f and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDf THETYPE OF 
OUTPUT DEUICE TO BE USEDf THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACOUIREDJ 

If: THE* ORGANIZATION'S STRUCTURE is decent ral ized 

Then: 1) There is stronsly su^53estive evidence (*8) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is real-time f 

2) There is stronsly su^^estive evidence (#8) that THETYPE 
OF OUTPUT DEUICE TO BE USED is individual-terminals r 

3) There is strongly susisJestive evidence (♦S) that THE 
RECOMMENDED INSTALLATION TO BE USED is divisional . and 

4) There is strondly susisiestive evidence (*8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is hire- 
special ists 



premise: ($AND (same CNTXT informal DECENTRALIZED)) 

action: (DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 300) 

(CONCLUDE CNTXT OUTPUT INDIVIDUAL-TERM INALS TALLY 
800) 

(CONCLUDE CNTXT INSTALL DIVISIONAL TALLY 800) 
(CONCLUDE CNTXT IRG HIRE-SPECIALISTS TALLY 800)) 

CORGRULEST 



RULE023 



CThis rule applies to ORGANIZATION f and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDf THETYPE OF 
OUTPUT DEVICE TO BE USEDf THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED: 

If: THE LEADER'S STYLE OF OPERATION is task-oriented 

Then: 1) There is strongly susJdestive evidence (*8) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is real-timef 

2) There is stroni^ly suddestive evidence (.8) that THETYPE 
OF OUTPUT DEVICE TO BE USED is indi vidual -term ina 1 s f 

3) There is strondly suddestive evidence (*3) that THE 
RECOMMENDED INSTALLATION TO BE USED is pyramidalr and 

4) There is suddestive evidence (*5) that THE RECOMMENDEI' 
TRAINING OR ASSISTANCE TO BE ACQUIRED is unavailable 



premise: ($AND (same CNTXT style task-oriented)) 

action: (DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUTPUT INDIVIDUAL-TERMINALS TALLY 
800) 

(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 800) 
(CONCLUDE CNTXT TRG UNAVAILABLE TALLY 500)) 

CORGRULES: 
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RULE024 



CThis rule applies to ORGANIZAT ION r and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDf THETYPE OF 
OUTPUT DEVICE TO BE USEDr THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED! 

If: THE INDIVIDUAL'S TECHNICAL TRAINING IN DECISION ANALYSIS is 

hiEih 

Then: 1) There is strongly su^destive evidence (»8) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is real-timer 

2) There is strondly suddestive evidence <*8) that THETYPE 
OF OUTPUT DEVICE TO BE USED is individual-terminals r 

3) There is strondly suddestive evidence (*8) that THE 
RECOMMENDED INSTALLATION TO BE USED is pyramidalr and 

4) There is strondly suddestive evidence <*8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is 
t rain-existind-staf f 



premise: <$AND <SAME CNTXT training HIGH)) 

action: (DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUTPUT INDIVIDUAL-TERMINALS TALLY 
800) 

(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 800) 
(CONCLUDE CNTXT TRG TRA IN-EXI STING-STAFF TALLY 800)) 

CORGRULES! 



RULE025 



CThis rule applies to ORGANIZAT ION r and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDr THETYPE OF 
OUTPUT DEVICE TO BE USEDr THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED! 

If: THE INDIVIDUAL'S TECHNICAL TRAINING IN DECISION ANALYSIS is 

low 

Then: 1) There is strondly suddestive evidence (*8) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is non- real -time r 

2) There is strondly suddestive evidence (*8) that THETYPE 
OF OUTPUT DEVICE TO BE USED is 1 a rde-sc reen-di sp 1 ays r 

3) There is strondly suddestive evidence (*8) that THE 
RECOMMENDED INSTALLATION TO BE USED is divisional r and 

4) There is strondly suddestive evidence (*8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is hi re- 
special ists 



premise: 

action: 



($AND (SAME CNTXT TRAINING LOU)) 

(DO-ALL (CONCLUDE CNTXT TYPSYS NON-REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUTPUT LARGE-SCREEN-DISPLAYS TALLY 



800) 

(CONCLUDE CNTXT INSTALL DIVISIONAL TALLY BOO) 
(CONCLUDE CNTXT TRG HIRE-SPECIALISTS TALLY 800)) 



CORGRULES! 
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RULE026 



CThis rule applies to ORGANIZATION r and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDr THETYPE OF 
OUTPUT DEUICE TO BE USEDr THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED! 

If: THE TECHNOLOGICAL METHODS AVAILABLE is analyt ical-aids 



Then: 1) There is stronSly su^Sestive evidence (*8> that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is real-timer 

2) There is strondly su^^estive evidence (^S) that THETYPE 
OF OUTPUT DEVICE TO BE USED is indi vidual -termina 1 s r 

3) There is sussestive evidence (*5) that THE RECOMMENDED 
INSTALLATION TO BE USED is F'^ramidalr and 

4) There is stroni^ly sudSestive evidence (*8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is 
unava liable 



PREMISE: ($AND (SAME CNTXT METHODS ANALYTICAL-AIDS)) 



action: (DO-ALL (CONCLUDE CNTXT 

(CONCLUDE CNTXT 
800) 

(CONCLUDE CNTXT 
(CONCLUDE CNTXT 



TYPSYS REAL-TIME TALLY 800) 

OUTPUT INDIVIDUAL-TERMINALS TALLY 



INSTALL PYRAMIDAL TALLY 500) 
TRG UNAVAILABLE TALLY 800)) 



CORGRULES! 



RULE027 



CThis rule applies to ORGANIZATION r and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDr THETYPE OF 
OUTPUT DEVICE TO BE USEDr THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED! 

If: THE TECHNOLOGICAL METHODS AVAILABLE is inventory-aids 

Then: 1) There is sudsestive evidence (*5) that THE TYPE OF SYSTEM 

RECOMMENDED TO BE USED is real-timer 

2) There is suddestive evidence (*5) that THETYPE OF OUTPUT 
DEVICE TO BE USED is indi vidual-termina Is r 

3) There is suddestive evidence (*5) that THE RECOMMENDED 
INSTALLATION TO BE USED is pyramidalr and 

4) There is suddestive evidence (*5) that THE RECOMMENDED 
TRAINING OR ASSISTANCE TO BE ACQUIRED is unavailable 



premise: (iAND (SAME CNTXT METHODS INVENTORY-A IDS ) ) 



action: (DO-ALL (CONCLUDE CNTXT 

(CONCLUDE CNTXT 
500) 

(CONCLUDE CNTXT 
(CONCLUDE CNTXT 

CORGRULES! 



TYPSYS REAL-TIME TALLY 500) 

OUTPUT INDIVIDUAL-TERMINALS TALLY 

INSTALL PYRAMIDAL TALLY 500) 

TRG UNAVAILABLE TALLY 500)) 
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RULE023 



CThis rule applies to QRGANIZATIONr and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDr THETYPE OF 
OUTPUT DEVICE TO BE USEDf THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMEl^DED TRAINING OR ASSISTANCE TO BE ACQUIRED! 

IfJ The technolodical knowledde-level is skilled 

ThenJ 1) There is suddestive evidence < 45 ) that THE TYPE OF SYSTEM 
RECOMMENDED TO BE USED is unavailabler 

2) There is suddestive evidence (*5) that THETYPE OF OUTPUT 
DEVICE TO BE USED is unavai lable f 

3) There is suddestive evidence < 45 ) that THE RECOMMENDED 
INSTALLATION TO BE USED is unavailablef and 

4) There is strondly suddestive evidence (^S) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is do- 
no t -hi re-special 1 sts 



premise: <$AND (same CNTXT knowledge-level SKILLED)) 



action: (DO-ALL (CONCLUDE CNTXT 

(CONCLUDE CNTXT 
(CONCLUDE CNTXT 
(CONCLUDE CNTXT 
800) ) 

CORGRULES! 



TYPSYS UNAVAILABLE TALLY 500) 
OUTPUT UNAVAILABLE TALLY 500) 
INSTALL UNAVAILABLE TALLY 500) 

TRG DO-NOT-HIRE-SPECIALISTS TALLY 



RULE029 



CThis rule applies to ORGANIZATION f and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDr THETYPE OF 
OUTPUT DEVICE TO BE USEDr THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED! 

If: The technolodical knowledde-leve 1 is unskilled 

Then: 1) There is strondly sudd€?stive evidence (* 8 ) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is unavailabler 

2) There is strondly suddestive evidence ( 48 ) that THETYPE 
OF OUTPUT DEVICE TO BE USED is unavailabler 

3 ) There is strondly suddestive evidence (48) that THE 
RECOMMENDED INSTALLATION TO BE USED is unava i 1 ab le r and 

4) There is strondly suddestive evidence ( 48 ) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is hire- 
specialists 



premise: ($AND (same CNTXT knowledge-level UNSKILLED)) 

action: (DO-ALL (CONCLUDE CNTXT TYPSYS UNAVAILABLE TALLY 800) 

(CONCLUDE CNTXT OUTPUT UNAVAILABLE TALLY 800) 
(CONCLUDE CNTXT INSTALL UNAVAILABLE TALLY 800) 
(CONCLUDE CNTXT TRG HIRE-SPECIALISTS TALLY 800)) 

C0RGRULE5! 
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RULE030 



CThis rule applies to ORGANIZATION f and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USED^ THETYPE OF 
OUTPUT DEVICE TO BE USED. THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED^ 

If: THE ORGANIZATION'S STRUCTURE is line 

Then* 1) There is strori:Sly sufiSestive evidence (*8) that THE TYPE 
OF SYSTEM RECOMMENDED TO BE USED is real-time. 

2) There is stronslly suSdestive evidence (*8) that THETYPE 
OF OUTPUT DEVICE TO BE USED is unavai lable . 

3) There is strondly susJs^estive evidence (*8) that THE: 
RECOMMENDED INSTALLATION TO BE USED is pyramidal, and 

4) There is stronsly susisestive evidence (»8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is 
unava i labl e 



premise: ($AND (same CNTXT formal LINE)) 

action: (DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUTPUT UNAVAILABLE TALLY 800) 
(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 800) 
(CONCLUDE CNTXT TRG UNAVAILABLE TALLY BOO)) 



CORGRULESJ 



RULE031 



CThis rule applies to ORGANIZATION . and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USED. THETYPE OF 
OUTPUT DEVICE TO BE USED. THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED: 

If: THE ORGANIZATION'S STRUCTURE is functional 

Then: 1) There is stronSly su^aestive evidence («8) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is non- rea 1-t i me . 

2) There is stronsly suaflestive evidence (.3) that THETYPE 
OF OUTPUT DEVICE TO BE USED is unavailable. 

3) There is stronSly su^iSestive evidence (.8) that THE 
RECOMMENDED INSTALLATION TO BE USED is divisional, and 

4) There is stronsily sufidestive evide^nce (.8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is 
unavai 1 able 



premise: 

action: 



(liAND (SAME CNTXT FORMAL FUNCTIONAL)) 

(DO-ALL (CONCLUDE CNTXT TYPSYS NGN-REAL-TIME TALLY 000) 



(CONCLUDE CNTXT OUTPUT UNAVAILABLE TALLY 800) 
(CONCLUDE CNTXT INSTALL DIVISIONAL TALLY 800) 
(CONCLUDE CNTXT TRG UNAVAILABLE TALLY 800)) 



CORGRULES: 
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RULE032 



CThis rule applies to ORGANIZATICJN f and is tried in order to find out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDr THETYPE OF 
OUTPUT DEVICE TO BE USEDr THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIREDD 

If: THE ORGANIZATION'S STRUCTURE is matrix 

Then: 1) There is stronsily sussiestive evidence (*8) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is non- real-time r 

2) There is stron^ily sui^^estive evidence (*8) that THETYPE 
OF OUTPUT DEVICE TO BE USED is unavailabler 

3) There is strondly su^sJestive evidence (♦S) that THE 
RECOMMENDED INSTALLATION TO BE USED is divisionalr and 

4) There is stronalu su5Js3estive evidence (*8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is 
unavai 1 able 



premise: ($AND (same CNTXT formal MATRIX)) 

action: (DO-ALL (CONCLUDE CNTXT TYPSYS NON-REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUTPUT UNAVAILABLE TALLY 800) 
(CONCLUDE CNTXT INSTALL DIVISIONAL TALLY 800) 
(CONCLUDE CNTXT TRG UNAVAILABLE TALLY 800)) 



L'ORGRULEST 



RULE033 



CThis rule applies to ORGANIZATION r and is tried in order to find out 
about the recommended informal structure!! 

If: THE ORGANIZATION'S STRUCTURE is notavailable 

Then: There is strongly sussestive evidence (*R) that the 

recommended informal structure is centralized 



premise: ($AND (same CNTXT informal NOTAVAILABLE) ) 

action: (CONCLUDE CNTXT UNKSTRUC CENTRALIZED TALLY 800) 

CORGRULESD 



RULE034 



CThis rule applies to ORGANIZATION? and is tried in order to find out 
about tT)e recommended informal structure!! 

If: The recommended informal strijcture is known 

Then: It is definite (1*0) that the following is the recommended 

informal structijre: THE 

RECOMMENDED INFORMAL STRUCTURE TO USE IS <unkstruc> 



premise: ($AND (known CNTXT UNKSTRUO) 
action: (CONCLUDETEXT CNTXr UNKSTRUC (TEXT NIL 

•THE 

RECOMMENDED INFORMAL STRUCTURE TO USE IS“ 

(VALl CNTXT UNKSTRUC)) 



TALLY 1000) 
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I 







RULE035 



CThis rule is def ini tional ? applies to ORGr^NIZAT ION ^ and is tried 
when information is received about the recommended informal 
st ructureD 

Ift An attempt has been made to deduce the recommended informal 
structure 

Then* Display the recommended informal structure 



premise: ($AND (ONCEKNOUN CNTXT UNKSTRUC t)) 

action: (PRINTCONCLUSIONS CNTXT UNKSTRUC) 

CORGRULES/antecedent U 



RULE036 



CThis rule applies to ORGAN IZATION y and is tried in order to firvi out 
about THE TYPE OF SYSTEM RECOMMENDED TO BE USEDr THETYPE OF 
OUTPUT DEVICE TO BE USEDr THE RECOMMENDED INSTALLATION TO BE 
USED or THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUtREO.1 

If: THE IMPLEMENTATION/CONSTRUCTION STATUS OF THE SYSTEM 

Then: 1) There is strori5ily suifiSestive evidence (»3) that THE TYPE 

OF SYSTEM RECOMMENDED TO BE USED is real-timer 

2) There is stronelu suFJ^estive evidence (»3) th£)t niETYPE 
OF OUTPUT DEVICE TO BE USED is indi vidual -terminal . 

3) There is stronfily su^sestive evidence (»B) that THE 

RECOMMENDED INSTALLATION TO BE USED is pyramidair and 

4) There is strongly su^sestive evidence (»8) that THE 
RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED is 
t rain-exi stinH“Staf f 



premise: 

action: 



($AND (SAME CNTXT SYSSTAT YES)) 

(DO-ALL (CONCLUDE CNTXT TYPSYS REAL-TIME TALLY 800) 

(CONCLUDE CNTXT OUTPUT INDI VIDUAL-TERMINALS TALLY 



800) 

(CONCLUDE CNTXT INSTALL PYRAMIDAL TALLY 800) 
(CONCLUDE CNTXT TRG t ra i n-exi st i hfi-s taf f TALLl 800)) 



CORGRULES: 



RULE039 



CThis rule applies to ORGANIZAT ION r and is tried in order to otjt 

about THE RECOMMENDED FORMAL STRUCTURED 

If: THE ORGANIZATION'S STRUCTURE is no tava i 1 ab 1 e 

Then: There is strongly su‘iiiestivo evidence (.8) that THE 

RECOMMENDED FORMAL STRUCTURE is line 



premise: (SAND (SAME CNTXT FORMAL NOTAVA ILABLE ) ) 

action: (CONCLUDE CNTXT FORSTRUC LINE TALLY BOO) 
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CORGRULESl 



RULEO^O 



CThis rule applies to ORGANIZATION f ' and is tried in order to find out 
about THE RECOMMENDED FORMAL STRUCTURED 



If: THE RECOMMENDED FORMAL STRUCTURE is known 

Then: It is definite (1.0) that the following is THE RECOMMENDED 

FORMAL structure: THE RECOMMENDED FORMAL STRUCTURE 10 USE 
IS <forstruc> 



premise: 

action: 



($AND ^'KNOUN CNTXT FORSTRUO) 
(CONCLUDETEXT CNTXT FORSTRUC (TEXT NIL 



•THE RECOMMENDED FORMAL STRUCTURE TO USE TS' 

(VALl CNTXT FORSn-dJO) 



TALLY 1000) 



CORGRULESD 



RULE041 



CThis rule is def ini t ional f applies to ORGANIZATION r and is tried 
when informat ion is received about THE RECOMMENDED FORMAL 
STRUCTURED 

If: An attempt has been made to deduce THE RECOMMENDED FORMAL 

STRUCTURE 

Then: Display THE RECOMMENDED FORMAL STRUCTURE 



premise: ($AND (ONCEKNOUN CNTXT FORSTRUC t)) 

action: (PRINTCONCLUSIONS CNTXT FORSTRUC) 

CORGRULES/antecedentD 

NIL 
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APPENDIX B 

DECAIDS PARAMETER LISTING 



DECAIDS ORG 
EN^^XRONMENT ORG 
FORMAL ORG 
FORSTRUC ORG 
INFORMAL ORG 
INSTALL ORG 
KNOULEDGE-LEMEL ORG 
LEADER-TRAINING ORG 



METHODS ORG 
ORGANIZATION UAL 
ORGRULES ALLNAMES 
OUTPUT ORG 
PROBDEF ORG 
PROBTYPE ORG 
STAFF GRG 
STFFTRG ORG 

PROP-ORG 



STRESS ORG 
STYLE ORG 
SYSSTAT ORG 
TRAINING ORG 
TRG ORG 
TYPSYS ORG 
UNKSTRUC ORG 



DECAIDS 



antecedent-in: (Ruleooi ) 

updated-by-the-uay: ( ruleooi ) 

UPDATED-BY : ( RULE002 ) 

TRANS : (THE DECISION) 

LEGALUALS: TEXT 

multiualued: t 

ENVIRONMENT 



TRANS : ENVIRONMENT) 

prompt: (UILL you comment on the LEADER-’^RAINING OR THE 

STAFF-TRAINING OF THE ENVIRONMENT OF THE ORGAi M! ZAT I ON ) 
expect: (LEADER-TRAINING STAFF-TRAINING ) 

labdata: T 

FORMAL 



USED-BY: (Rules 39 32 31 30 17 16) 

TRANS : (THE ORGANIZAT ION ' S STRUCTURE) 

prompt: (THE FORMAL STRUCTURE OF THE ORGANIZATION CAN BE DEFINED AS 

EITHER LINEf STAFFr MATRIX- FUNCTIONAL.- OR 
NOTAVAILADLE» IF FURTHER EXPLANATION OF THESE TERMS IS 
NEEDED? TYPE A QUEST IGM MARK* UHAT IS THE 
ORGANIZATION'S FORMAL STRUCTURE'!’) 
expect: (LINE STAFF FUNCTIONAL MATRIX NOTAVA ILABLE ) 

laddata: T 

REPROMPT: (LINE - EMPHASIZES DIRECT CHAINS OF AUTHORITY AND UNITY OF 

COMMAND STAFF - INCLUDES AN INFORMATIONAL AND 
ADVISORY STAFF TO ASSIST AND GUIDE OPERAT L UNAL 
PERSONNEL PUNCTIOMAL - ARRANGES PERSONNEL FT 
FUNCTIONAL ACTIVITY SUCH AS LOGISTICS? 
COMMUNICATIONS? ETC» MATRIX - DRAWS PERSONNEL FROM 
ACROSS DEPARTMENTAL LINES) 

FORSTRUC 



UPDATED-DY: (RuIg‘5 39 SREFMAPK 40) 

USED-PY: (RULE040) 

containfd-in: (r;jleo40) 

antecedent-in: (RULE041 ) 

UPDATED-DY-THE-WAY: (RULE041 ) 

TRANS : (THE RECOMMENDED FORMAL STRUCTURE) 

expect: (LINE STAFF FUNCTIONAL MATRIX) 
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INFORMAL 



USED-DY: (Rules 33 22 21 19 18 15 3) 

TRANS: (THE ORGANIZATION ' S STRUCTURE) 

prompt: (THE INFORMAL STRUCTURE OF THE ORGANIZATION REFERS TO THE 

MANNER IN UIIICH COMMUNICATION IS ACCOMPLISHED . IS THE 
INFORMAL STRUCTURE BEST DESCRIBED AS CENTRA!.. I ZED y 
CONGULTATIUE^ TRANSACT IGNAL - PART I ALL Y-DELEGATE.D 
DECENTRALIZEDr OR NOTAUAILABLE IF FURTHER EXPL.T: 'A FIGN 
IS NEEDEDf TYPE A QUESTION MARK.) 

expect: (CENTRALIZED CONSULTATIUE TRANS ACT IGNAL PARTIALLY- 

DELEGATED DECENTRALIZED NOTAUAILABLE ) 

labdata: T 

reprompt: (CENTRALIZED - USES A FOCUSED FLOW OF AUTHORITY TO A 

SINGLE SOURCE AT THE TOP UF THE HIERARCHY 
CONSUI.TATIUF - MAXIMIZES PATTERNS OF CEN IRAL n.'^TROL 
BUT ENCGURAGF.S UERTICAL AND UPWARD COMMUN.T C A I f i OF 
ADVICE AND GUIDANCE FROM A PROFESSIGNAL STAPi- 
TRANSACTIONAL - STRESSES OPEN COMMUN ICAT ION 
DELIBERATION^ AND NEGOTIA I ION • BOTH LATERrU.LY t.?: jMXjy 
LEVELS AND VERTICALLY AMONG LEVELS. AUTHGRirv MA / 
STILL REMAIN AT/WITH TOP MANAGEMENT PARTIALLY 
DELEGATED - DISTRIBUTES AUTHORITY AMONG PRUn:/- -0!!AL 
STAFF WHILE INCREASING THE NEED FOR CO-OP, i.L-F' f ON OF 
EFFORT. THE STAFF MAY POSSESS AUTHORITY 10 C L' •*:i..OP 
ACTION ALTERNATIVES BUT TOP MANAGEMENT STILL PCTA.IMS 
THE RIGHT TO REJECT AND MODIFY DECENTRAL IZED - 
DELEGATES AND DISPERSES FULL DEC IS I ON-MAKING fX-.iER 
TO STAFF AT LOWER LEVELS OF THE HIERARCHY) 

INSTALL 



USED-BY: (RULE002) 

contained-in: (rule:oo2) 

UPDATED-BY: (RuIgs 36 32 31 30 29 28 27 26 25 24 23 22 21 20 1? 18 

17 16 15 14 13 9 8 76543) 

TRANS : (THE RECOMMENDED INSTALLATION TO BE USED) 

expect: (PYRAMIDAL DIVISIONAL UNA VA TLA.OLE ) 

reprompt: (A divisional installation places authority in each 

division for i r i d o p e? n d e n t s y s t e iri s w fi i .1 e p y r a iti i o' d 1 
installations place authorityat the top of one.' 
super-system above all divisions.) 



KNOWLEDGE-LEVEL 



USED-BY 
TRANS : 

prompt: 



expect: 

LABDATA 



(Rules 29 28) 

the technological knowleds'e- 1 eve 1 ) 

(IN REGARDS TO THE TECHNOLOG I CAl. TRAINING REQUIRED 10 

ACCOMPLISH THE TASK y IS THE LEVEL OF TECHNICAL TRAINING 
CONSIDERED TO BE SKILLED^ UNSKILLEDf OR UNKNOWN-’.^ 
(SKILLED UNSKILLED) 

T 



LEADER-TRAINING 



USED-BY: (Rules 5 4) 

TRANS: (THE LEADEirS LEVEL OF TRAINING) 

prompt: (Is the task leader's tecf-inical training considered to he 

skill t^d f unsk i 1 led r o r unknown? ) 
expect: (SKILLED UNSKILLED) 

LABDATA : T 
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METHODS 



USED-BY: (Rules 27 26) 

TRANS: (THE TECHNOLOGICAL METHODS AVAILABLE) 

prompt: (ARE THE TECMNOLOG TCAL METHODS USED ANAL YT TCAL-A I DC . 

INVENTORY-AIDS. OR UNKNOUN'^^) 
expect: (ANALYTICAL-AIDS INVENTORY-AIDS ) 

labdata: T 

reprompt: (Inventory aids refer to administ rati ve uses and 

analytical aids are those which concern sc iei j t i. P i.c 
appl ications ♦ ) 

OUTPUT 



USED-BY: (RULE002) 

CONTAINED- in: (RMLE002) 

UPDATED-DY: (Rules 36 32 31 30 2^ 23 27 26 23 2*1 23 22 21 20 ^ 13 

17 16 13 14 13 9 S 7 6 T5 4 3) 

T R A N S : ( t e type of o r j t p * j (v ^ I p v :L c e t o b o* i j 'i ) 

E X F' E C T : ( I D I V I D U A L - T E R M I N A L. S L A R G E - S r: E E N Ti I S P 'P S U N A A I L„ - ; ' . I... 

PROBDEF 



USED-BY : (Rules 14 13) 

TRANS : (THE TASK DEFINITION) 

prompt: (CONCERNING THE PldlBLEM FACING THE ORGANIZATION. I.:.} '• 

PROBLEM CLEARLY DEFINED. AMBIGUOUS. OR UNKNOUN'^ • 
EXPECT : (CLEARLY-DEFINED AMBIGUOUS) 

labdata; T 

PRODTYPE 



TRANS : (THE TYPE OF PROBLEM TO BE SOLVED) 

prompt: (THIS PROGRAM IS DESIGNED 10 PROVIDE MANAr'ER^ AT ALf. • EVEl. 

WITH ADVrCE CONCERNING I HE USE OF THEIR CDMI'in-' 
RESOURCES. IN ORDER TO FRO'M DE THIS IjHF ORMAT I • ^ ' n!E 
USER WILL DE ASKED TO FURNISH DATA CGKJCERNINl ' 
ORGANIZATION. ITS LEVEL OF TRAINING^- THE 
ORGANIZATION'S LEA.DER. THE ENV IRQNMLNT AFFEOTTpi n-rE 
DECISION. AND THE TASK FACING THE Of^•^A^'IZA f 1 ''L i , mIAV 
IS THE TYPE OF PROBLEM WHICH THE ORGANIZAriON I- A S 

expect: ANY 

labdata: t 

STAFF 



TRANS : (THE FORMAL COMPOSITION OF THE ORGANIZATION'S 5TRUC lU!- • 

prompt: (IS THE STAFF'S TECHNICAL TRAINING SKILLED* UNSK ILLE.:- •• UR 

UNKNOWN?) 

EXPECT : ( SKILLED UNSKILLED ) 

labdata; T 

STFFTRG 



USED-BY : (Ruler, 7 6) 

TRANS: (THE STAFF'S LEVEL OF TFCIINTCAL rRAINTNG) 

prompt: (IS THE GICGANIZATTON'S STAFF ' S t FIVEL OF rFCHL'ICAL IRAlr'ING 

IN THE USE OF COMPUTER IZED lI-niNTCAL AIDS CQNSLiDf L: D 
SKILLED* UNSKILLED* OR UNKNOWN'-") 
expect: (SKILLED UNSKILLED) 

labdata: T 
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STRESS 



USED-BY: (Rules 9 8) 

TRANS : (THE LEVEL OF THE TASK'S STRESS) 

prompt: (IS THE STRESS LEVEL CONSIDERED TO BE HIGHr LOWr OR UNKNOWN?) 

expect: (HIGH LOW) 

labdata: r 

STYLE 



UGED-BY: (Rules 23 20) 

TRANS : (THE LEADER'S STYLE OF OPERATION) 

prompt: (IS THE TASK LEADER'S STYLE BEST DESCRIBED AS 

RELATION-ORIENTED r TASK-GR HINTED OR UNKNOWN? ) 
expect: (RELATION-ORIENTED TASK-ORIEN lED ) 

labdata: T 

R E P R 0 M F' T : (reJ.Hjti.on or :i. e r.- 1 e rJ refers to t e I e e d e r w h o i}i i * / v..- iis i. ! J 1 1 e 
d i r e c 1 1 o ri t a b i. s s t hj f f' ? e r i c our 3 .s e t h c? 1 3 f . ■ ■ 

actively pa r 1 1 c i. p b t ;i n 'S e t L :i rt s d e c i s i o ri in . ! • 
p 3 r 3 m e t e r s 7 3 r» d v 3 1 li e (.. h d e v e 1 o p iti e ri t o f >■ cm • i n i 1 
r e s p o n s i b .i. 1 i t \ } * T a s k o t' i e n 1 n .1 c- 3 d -? r s a r e • ' c.- r ' 1 1 1 • .;j 
as those u 1) o p t' e f e v f a r iri o t' e c: e i"i t r a 1 i z a t i o 1 1 • ; r 
c o n t r (3 1 a ri d a r e 1 e s s c o ri r' e r i"< e d w j. t t h e d : » 1 1 ■ ! 1 1 

of i n d i V i. ci u a 1 e s p o i j s i b 1 1 i t y i i"i the d e c i s ;i. c.m Ti . • Ki i i .\i 
process ♦ ) 

SYSSTAT 



USED-BY: (RULE036) 

TRANS : (THE IMPLEMENTAT lON/CONSTRUCT ION S '^ATUS OF THE SYCTE:) 

prompt: (DOES AN OPERATIONAL SYSTEM CURRENTLY EXIST?) 

expect: (YES NO) 

labdata: t 

TRAINING 



USED-BY: (Rijle<3 2S 24) 

TRANS: (THE INDIVIDUAL'S TECHNICAI.. TRAINING IN DECISION ANAL'r 'H': S ) 

prompt: (IS THE task LEADER'S LEVEL OF TECHNJ'CAL TRAINING liUNU T DERED 

TO BE HIGHr LCJUr OR UNKNOWN?) 
expect: (HIGH LOU) 

TRG 

UGED-BY : (RULE002) 

CONTAINED-IN: (RULE002) 

UPDATED-BY: (Rules 36 32 31 30 2? 28 27 26 25 24 23 22 21 20 1.9 LB 

17 16 15 14 1.3 9 0 7 6 5 4 3) 

TRANS: (THE RECOMMENDED TRAINING OR ASSISTANCE TO BE ACQUIRED’ 

expect: (HIRE-SPECIALISTS DO-NGT-HIRE-SPECIALIS IS TRA T N-EX I B I ■ f -G 

STAFF UNAVAILABLE) 

TYPSYS 



USED- by: (RULE002) 

CONTAINED-IN: (RULE002) 

UPDATED-DY: (Rules 36 32 31 30 29 28 27 26 25 24 23 22 21 20 19 10 
17 16 15 14 13 9 0 7 6 543) 

TRANS : (THE TYPE OF SYSTEM RECOMMENDED TO DE USED) 

expect: (REAL-TIME NON-REAL-TIME UNAVAILADLE) 
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(JNKSTRUC 



UPDATED-BY: (Rules 33 SREFMARK 3A) 

USED-BY: (RULE034) 

CONTAINED-IN: (RULE034) 

ANTECEDFNT-IN ; ( RULE035 ) 

UPDATED-DY-THE-WAY: (RULE035) 

TRANS J (the reconrinicnded irifonrial structure) 

expect: (CENTRALIZED DECENTRALIZED CONSULTATIVE TRANSACT lONAL 

PARTIALLY-DELEGATED) 

'^LPROP-VAL 

^XPROP-VAL 

PROP-VAL 



ORGANIZATION 



TRANS : (THE ORGANIZATION ) 

MAINPROPS: (PRGDTYPE FORMAL INFORMAL STFFTRG LEADER-TRA INIiR 

PROBDEF knowledge-level STRESS SYSSTAT METHOD: ' 

proptype: prop-grg 

type: organization- 

RULETYPES : ( ORGRULES ) 

goals: (DECAIDS unkstruc forstruo 

'"LALLNAHES 

"'XALLNAMES 

ALLNAMES 



ORGRULES 



context: (ORGANIZATION) 

SVAL : ( ORGANIZATION ) 

CTRANS : ORGANIZATION 

NIL 
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APPENDIX C 

SAMPLE CONSULTATION 



BEGIN) 

Special options (type ? for help): 

FT 4 

Instructions? (Y or N) 

NO 

ORGANTZATTGN-2 

1) THIS PROGRAM IS DESIGNED TO PROVIDE MANAGERS AT ALL LEVEL’ > 01 TH 
ADVICE CONCERNING TME USE OF THETR COMPUTER RESOURCES* IN 
ORDER TO PROVIDE THIS INFORMAT ION , THE USER UILL DE ASKED TO 
FURNISH DATA CONCERNING: MTS ORGANIZATION v ITS LEVEL OF 
TRATNINGr THE ORGAN IZA T TON ' S LEADER-' THE EN‘M:R0NMENT AFF-i ^TNO 
THE DECISION. AND THE TASK FACING THE ORGAN I ZA 1 1 ON ♦ UllAl rS 

THE TYPE or PRODLEM UHICH THE GROANIZAriON FACES'? 

the:sis 

2) THE FORMAL STRUCTURE OF THE ORGANIZATIPN CAN BE DEFINFD 
EITHER LINE. STAFF* MATRIX* FUNC IIONAL ^ OR NGTA VAILADLL .. 

FURTHER EXPI..ANATIGN OF THESE TERMS IS NLFDFTa TYPE A 0UF'-T:0N 
MARK* UHAT IS THE ORGANIZATION 'S FORMAL STRUCTURE'? 

NOTAVAI LADLE 

3) THE INFORMAL STRtiCTURE OF THE ORGANIZATION REFERS TO TMi:: i'-AilNER 
IN WHICH CCMMUNICATIGN IS ACCOMPLISHED* fS THE TNFGPMAL 
STRUCTURE PEST DESCRTBED AS CENTRALTZEDv CONSUL TAT I VHI . 
TRANSACTIONAL . PARTIAL L Y-DELEGATED - DECEMTRAI . I ZED * OR 
NOTAVAILABLET IF FURTHER EXPLANATION IS NEEDED^ TYPE A OULSTION 
MARK . 

NOTAVAILABLE 

4) IS THE ORGANTZATTOfr S STAFF'S LEVFL OF TECHNICAL TRAINING !.N 
THE USE OF COMPUTERIZED TECHNICAL AIDS CONSIDERED SKILLED- 
UNSKILLED. OR UNKNOWN'? 

SKILLED 

5) Is the^ task leader's technical trainirr-i coiis idered to be 
skilled, unskilled, or unknoi^^nT 

tt SKILLED 

6) IS THE TASK LEADER'S STYLE PEST DFSCRIDED AS RELATION- 
ORIENTED . TASK-GR TENTED * GR UNKNOWN'? 

RELATION-ORIENTED 

7) CONCERNING THE PRODLEM FACING THE ORGANIZATION . IS THE PRODLEM 
CLEARLY-DEFINED* AMBIGUOUS. GR UNKNOWN'? 

CLEARLY-DEFINED 

8) IN REGARDS TO TME TECHNOLGG ICAL TRAINING REQUIRED TO ACCGMf I.. I SH 
THE TASK. IS THE LEVEL OF TECMNICAL TRAINING CONSIDERED iQ BE 
SKILLED. UNSKILLED. OR UNKNOWN'? 

SKILLED 

9) IS THE STRESS LEVEL CONSIDERED TO DE HIGH* LOW. GR UNKNOWi’-' 

HIGH 

10) DOES AN OPERATIONAL SYSTEM CURRENTLY EXIST'? 

'Mt NO 

11) ARE THE TECHNOLOGICAL METHODS USED ANALYTICAL-AIDS . INVEN TOR Y- 
AIDS. of;: UNKNOWN'? 

ft ANALYTICAL-AIDS 

-- -Cn Findout: DECAIDS of ORGANTZATIGN-S 
Tryinsl RULE002/ORCAN T ZAT I ON-2 ; 

--C2: Findout: TYPSYS of ORGAN I ZA T I ON -2 
RULE036 failed Cm preview} dun to clause 1 

RULE032 failed Cif'i previt.‘w> due to clause 1 

RULE031 failed Cm previewT due to c1<hisd 1 
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RULE030 failed <in preview> due to clause 1 
F<ULE029 failed <in preview> due to clause 1 
Tryind RULE02a/0RGANI2ATI0N--2 ? RULE020 succeeded. 

Conclude: TYPSYS of ORGANIZATION-2 is UNAOAILADLE (.5) 

Conclude: OUTPUT of ORGANIZATION-2 is UNAUAILAPLE (.5) 

Conclude: INSTALL of ORGANIZAT jnN-2 is UNAUATLABLE (.3) 

Conclude: TRG of 0RGANI2ATI0N-2 is DO -NOT-HIRE-SPECI ALISTS (.8) 
RULE027 failed <in r-peview> due to clause I 
Tryins RULE026/0RGANIZATIGN-2 ? RULE026 succeeded. 

Conclude: TYPSYS of 0RGANI2ATIC)N-2 is REAL-TIME (.8) 

Conclude: OUTPUT of ORGANIZATIOfL-2 is INDIVIDUAL-TERMINALS (.8) 
Conclude: INSTALL of ORGANIZATION-2 is PYRAMIDAL (.5) 

Conclude: TRG of ORGANIZATION-2 is UNAVAILADLE (.8) 

Try ins RULE023/0RGANIZATI0N-2; 

— Cno rules to conclude TRAINING of ORGANIZATION-2.1 
12) IS THE TASK LEADER'S LEVEL OF" lECHNICAL TRAINING CONSIDERED TO 
BE HIGHt LOU. OR UNKNOWN'^ 

HIGH 

RULE023 failed due to clause 1 

Tryind RULE02A/0RGANIZATI0N-2 ? RULE02A succeeded. 

Conclude: TYPSYS of ORGANIZA T ION-2 i. REAL-TIME (..^ 6 ) 

Conclude: OUTPUT of ORGANIZATTON-2 is INDIVIDUAL-TERMINALS (.86' 
Conclude: INSTALL of ORGANIZATION-2 is PYRAMIDAL (.9) 

Conclude: IRQ of ORGANIZATION -2 is TRAIN- EXISTING -STAFF (.8) 

F\ULE023 faile^d (in nreviewT due to clause 1. 

Fi'ULE022 fjiiled <in proview> due to clause I 

FNJLE021 failed -Cin r-rev'iew> due to clause 1 

Tryins RULE020/0RGANIZA riON-2 ? RULE020 succeeded. 

Conclude: TYPSYS of ORGANIZATION-2 is NON-REAL-TIME (.8) 

Conclude: OUTPUT of ORGANIZATTON-2 is LARGE-SCREEN -DISPLAYS (.8) 
Conclude: INSTALL of ORGANIZATION-2 is DIVISIONAL (.8) 

Conclude: TRG of ORGANIZATION-2 is TRAIN-EXISTING-STAFF (.96) 
r-'(ULE019 failed <in ereviewT due to clause I 

RULE018 failed Cin preview.! due to clause; 1 

RUI.E017 failed Cin preview! due to clause 1. 

RULE016 failed -Cin preview! due to clause 1 

R'ULEOIS failed Cin preview! due to clause 1 

RULEOl.) fffiled Cin preview! due to clause I 

Tryin.s RULE0.1.3/0RGANT2ATT0N-2? RULE013 siicceeded. 

Conclude: TYPSYS of ORGANIZATION-2 is REAL-TIME (.992) 

Conclude: OUTPUT of ORGANIZATION-2 i.s IND I VIDUAL -TERMINALS (.992) 
Conclude: INSTALL of ORGANIZA T 1 ON-2 is PYRAMIDAL (.88) 

Conclude: TRG of ORGANIZAT JON-2 is DO-NOT-HIRE-SPECIALISTS (.96' 
RULE009 foiled Cin .'^'review! due to clau-!.e .1. 

Tryind RULEOOO/nRGANIZATION-2 : RUI..E008 succeeded . 

Conclude: TYPSYS of ORGANIZATION -2 i.s KEAI-TIME (.998) 

Conclude: OUTPUT of ORGANIZATION -2 is IND L'lDUAL-TERMINALS (.9?o; 
Conclude: INSTALL of ORGANTZATION-2 is PYRAMIDAt. (.996) 

Ooncludo*. TRG of nRCANTZATION-2 is DO-NO T -HIRE-SPECIALISTS (.992) 
RULE007 failed Cin preview! due; to clause 1 
Tryins RULE006/nRGANTZATT0N-2; RULE006 succeeded. 

Conclude: TYPSYS of ORGANIZA T1 ON-2 is REAL-TIME (.999) 

Conclude: OUTPUT of ORGANIZA T TON-2 is INDIVIDUAL - TERMINALS (.99'’' 
Conclude: INSTALL of ORGAN T 7A I TON-:.’ is PYRAMTTiAI.. (.999) 

Conclude: TRO of ORGANIZATTON-2 i-.- DU-NOT- II TRE-SPECIALISTS (.990) 

Tryind RULCOOS/ORGAN TZA TTON -2 ’ RULE003 succeeded. 

Conclude: TYPSYS of ORGANIZAT lON-2 is RLAL-TIME (.999) 

Conclude: OUTPUT of ORGANIZA T rON-2 is IND I VTDIIAL -TERMI NALS (.99?) 
Conclude: INGTALI. of 0RGANT/.i'iTr0N-2 is UNAVAILABLE (.75) 

Conclude: TRG of 0RGANI7ATT0N-2 is II.TRE-SPECIALISTS (.6) 

Tryind RULEOCA/ORGAN I ZAT ION -2 1 RI.ILCOO-I succeodoJ . 

Conclude: TYPSYS of ORGANIZATION-.? is REAL-TIME (.999) 
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Conclude: OUTPUT of ORGANIZATTON-2 is INDIV IDUAL-TEPM IPiALS (.999) 
Conclude: INSTALL of ORGAraZATION-2 is PYRAMIDAL 

Conclude: TRG of QRGANIZATIGN-2 is DO-NGT-HIRE-SPECIAL .P' IG (.999) 
RULE003 foiled fin provieui> due to douse 1. 

— C23 Finished: TYPSYS of GRGANIZA TTGN-2 
--C23 Findout: OUTPUT of DRGANIZATI ON-2 

— C2D Finished: GUTPUT of OPGANIZA TTGN -2 
--C23 Findout: INSTALL of GRGANIZATTGN-2 
-- 'C2: Finished: INSTALL of ORGAN IZAT I GN -2 
— -C2D Findout: TRG of GRGANIZAT IGN-2 

— C2J Finished: TRG oT QRGANIZA riGN--2 
RULE002 succeeded . 

Conclude: DECAIDS of GRGANTZAT TON -2 is TEXT NIL 

USE THE FOLLOWING TYPE SYSTEM REAL-TIME 

THE OUTPUT SHOULD DE D [SPLAYED ON TNDI VI DUAL- TERMINALS 

THE MANNER GF INSTALLATION SHOUl D DE PYRAMIDAL 

AND THE RECOMMENDATION FOR TRAINING AND ASSISTANCE IS 

DO-NOT-HIRE-SPECIAL.rSTS . ( i .0 ^ 

— Cll Finished: DECAIDS of ORGArUZATION-.o 
antecedent RULE00.I. succeeded. 

Conclusions: T f -1 E Ti E C I CM 0 N a t' e a *.:> f n 1 .1. s * 

USE THE FOL..LGUTNG TYPE SYSTEM REAI..-T TME THE GUTCiir SHOULD DE 
DISPLAYED ON INDI VT DU lU.,- TERM INALS THE MAi 'NE'- UP 
INSTALLATION SHOULD DE PYRAMIDAL AMD THE IdP;. :: -MEND AT ION 
FOR TRAINING AND ASSISTANCE IS DG-NGT-HIRE '‘I LC I AL I STS . 

— C1.1 Findout: UNKSTRUC oT GRGANIZATIDN-2 
Tryiri£{ RULE033/0RGANIZATI0N-2 ? RULE033 succeeded. 

Conclude: UNKSTRUC of ORGANIZAT I ON-2 is CENTRALIZED ( v S '■ 

Trains RULE034/GRGANIZATION-25 RULE034 succeeded, 
antecedent RULE035 si.icceeded. 

THE 

RECOMMENDED INFORMAL STRUCTURE TO USE IS CENTRALIZED . 

Conclude: UNKSTRUC of GRGANIZATIQN-2 is TEXT NIL 
THE 

RECOMMENDED INFORMAL STRUCTURE TO USE IS CENTRALIZED ' J. , 0 • 

— Cll Finished: UNKSTRUC of ORGAN! ZAT IGN-2 

— C1.1 Findout: FGRSTRUC of ORGAN TZA T IGN-2 
TrvMns^ RULE037/GRnAN I ZAT I GM-2 ; R(JUI03^ succeeded . 

Conclude: FGRSTRUC of ORGANTZAT TON -2 is LTNL (.8) 

T r H i n R U F 0 4 0 / 0 R 0 A N T Z A T ] 0 N - 2 ^ R U L E 0 4 0 s u c' t:: e e d c' rf » 
a n t e c e d I'l t R l..f !... E 0 4 I 1 1 c c c •* c> d (? d . 

THE RECOMMENDED FORMAL STRUCTURE TO USE IS LINT . 

Conclude: FGRSTRUC of ORGANIZAT T ON-S is TEXT NIL 
THE RECOMMENDED FORMAL STRUCTURE TO USE IS LINE (1.0^ 

-- -C13 Finished: FORSTRUC of ORG.^NIZA TTON-2 
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APPENDIX D 

additional emycin/decaids parameter properties 

DefiniriEi Contexts 



MAINPROPS - 3 list of parameters to "trace" when a context of this t^n-e is 
created* Generall^:^ these are lahdata parameters whose velijes will 
always be needed in a consultation (see F^ARAMETERS ^ DOC I'oi' a 
definition of “ I abdata " ) ♦ The user will be asked for the value of 
each of these parameters as soon as a context is created ♦ This 
often serves to present a more coherent dialoi^ than would appear 
if each parameter were reouested when it w<as f i rst iiee»jed in a 
rule* It is also possible to h<3ve non-labda ta par<3me'. er for 
main pro PS if there is always someth i rid s/ou waiit to de'fice aiiout a 
new context* T e .d o ej 1 p a r a m e t e r ( s ) o f a s vj s t e m will i :• < a f a « j n d i n 

the MAINPROPS list of the main (or root) context typ'.:; ? i. ts 
placement here is what Sets the consultation started* 

PROPTYPE ~ an atom PROP-type which lists all paraineters which pe^'tain 
to this type of contc^xtr e ♦ d * r the PRQPTY1"‘E of" PERSGiN i. n MYCTN 
is PROP-PT / which contains such para'^ters as NAME? iaGE- SEiX« etc* 
When app lyind a rule* the system uses this property to tell which 
context in the tree a particular par<7jmeter belonds to* 



TYPE - an atom used to form the context identifier (by appending a 

numeral) for contexts of this type? e*d*? in MYCIN tlie TYPE of 
POSCUL (positive culture) is CULTURE-* 



RULETYPEiS - a list of all rule types applicable to this conte.''t (see 
RULEC*DOC)y e*d*r RULETYPES of POSCUL is the list (CULRULES 
POSCULRULES) * 

SYN - a template used for translating contexts of tliis type in 

ouGstions or rules* The SYN property is a list of entf'ies 
( < p a r m s .’••• f o r iti ’> ) ? w e r e <! p a r in s is a list of' o ri e or m t' e 

parameters of 1 1) e c o n t e t ? a n d • for' in ■ • i s a s i m p 1 e 1 1 s i f w o t' d s 

i n c 1 1.1 d i i“i d the e 1 e in e ri t s of p a r m s * T p a r a nri e t e r s m u t :< r r e a r' i 1 1 

the ii> a m e order in b o t li •• p a r m a n d • f n r iii s ? a r • d they mu t a 1 1 b e 

1 a b d a t a * The a t o m t is i j s ia d 1 i U e a p a r a iti e t c.^ r in p a i ' n i - . ' a i’ i d 
<foriTi> to represent the r^areni context* 

The system scans the SYN property until it fui'is an entry 
for which it knows the vali.ies of all parameters in prM'ms ^ values 
w^^ich were not supplic?d by the user will not be used* Gn<..'e an 
element of SYN h«is been selected? a t pans 1 at j on will i.'t^ 
constructed bu replacind each parameter in ■ form> witfi Kihat 
paranioter's valuer? t will be replace by t?ie t rans 1 at j i )ii (u<iind the 
SYN property) of tiie parent context* .parmsl and f’foTin' mnw he 
punctuated with semicolons donotind "places to stop* if the 
translation is unamb i dijous so far* E.d.? tlic eleinenl, ProiTi Uie S>YN 
property of an ordanism ((IDENT ? t) (the IDENT ? from t)) will 
result in "the K1 ebs ic? 1 1 a * if there aro no other ordanisms whose 

IDENT is Klebsiella? and "the Klebsiella from the blood culture" 
if there is* 

The simplest SYN is of the form ( ( ( p«a rm ) ( pa rm ) ) ) ? i*e.? 

^ parameter of the context whose value itself can stand 
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for the context r e * * r (((NAME) (NAME)))* If there is no SYN propr 

the context identifier (e*:sJ*r GRGANISM^l) will remain uii t rans 1 ated * 

UNIQUE - For use in conjunction with the SYN propt it controls w^lcther 
the context identifier needs to appear Ln the translation’ e * 5 i ♦ 

3 typical non-unioue phrase is 'the blood culture ( CUL 11 ild^ -2 ) ' r 
since it is possible to have more than one culture from the same 
site* If the UNIQUE property is Tr the context identi is 

omittedf e.d.f the root context type sihould have its UNUMiF 
property T* If UNIQUE is the atom '?'r tius means to .;>m i t the 
identifier if the first try at t I'ansl a t ind the context is* in 
factr uniouey e*d*r ify in the exan.ple above y CULTURE-2 w.^re the 
only blood culture in the consult then its translation would be 
simple 'the blood culture' ♦ Most context types are “non-unLouG' 
and will not have a UNIQUE Pioperty* The F^ropcrty is ru.'t 
necessary even on uniaue contcpxt? it exists simply to ro-duoe 
excess verbiast? where possible* 



If your system has no conte^xt treer you need only fill, in the 
properties listed above for the main (root) context type* If you hc:ve a 
non-trivial conte:^t trecy however? it is also necessary to sup ' U'.e 
fQllowin?^ properties for non-root types: PRGMPTIST (or Pllt.UiPTE'/'E.R > ;• 
PRGMPT2ND? ASSGCUITH? and GF-ESPRING* 



PRGMPTEVER - the “prompt" that will be printed when the first caii'x-ixrt 

of this type is created* Only conte.xt types that isfill t^LUAYS be 
created liave PROMPTEVERs? if you have to ask. whether tliere are 
any contexts of this type? then there should be a T'FvGMF-' f I ST instead* 
E*a*? in MYCIN? tliere is always at least one KNGWNGRf.) ijiMior every 
F‘ 0 S C U L ( b y d e f i ri i t i o n a positive c u 1 1 ij t' e i s o ri e f r o m i j i i. c' n o v a ri i sms 
drew)? so KNOWNORG has the PRGMPTEMER (The first orsnnisHt isolated 
from t will be referred to as**)* CIn PRGMPTEVER? PRGMPri.GT* 
and PR0MTP2ND? the ^ will be filled in by t^Je parent con text *11 

PRGMPTIST - the prompt askind whether contexts of this type e;xist* 

Unlike PFvOMPTEVER* this is a real Question and rcQuires :?n 
answer* E*d*? the PRGMPTIST of CURTHER is (Is ^ currently 
receiving therapy with any ani tm j crobial adent?)* 

PRGMPT2ND - the prompt askind whether additional contexts of this typ(? 

exist (to be used after at least one context of this tyru:.' has 
been created)* Oittission of t/iis property indicates tirai truiM'e is 
never more tlian one instance of the conte;;t under the rar^'rit 
context. E*d*? the PROMPTGNU of KNGUNQRG is OJere any other 
organisms isolated from ^ ?)♦ 

ASSOCUITf-1 - a list of ancestor contexxt types? showind this context 
type's location in the conterct tree* E.d* the ASSOCUl.l P! oT 
KNOWNORG in MYCIN is (PQGCUL PERSON) and the the AGSOCWTIII of PGSCUL 
is (F'ERSON)* Tin's mearis that a PGSCUL cent ex I. is diiv'ctlx below 
the patient context? an(j that a KNOWNGRG conte.xt is dirr'ctly below 
a PGSCUL* 

OFFSPRING - a list of descendent context types? indicating which types 

that can hand directly below a contf?xt of tliis typo in tiu.' coritext 
tree ♦ 
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Context types nay have other optional properties* If the context 
type is ever to appear in a ruler it iTiList have <i TRANS foi' tixa i"i 1 a t i o ri (see 
description of a TF\ANS property in PARAMETERS * DOC ) ♦ The ^ in the TRANS 
property of a context type is filled in by a translation of th»e tree 

root (main context)* If -you plan to use the SUMMARY optionr tlie context 
type will need a CNTXTSUMMARY property as described iri FEATURES * SUMMARY * 

If parmaters of the context type are to be fathered in a blocT ut i 
the TAB option for tabular innutr it will need the TABPARMSr TARHEijD* 
TERSEHEADr TADSTOPSr and LEGALTERM properties as described iii 
FEATURES * TABULAR-INPUT * 
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Properties of Parameters 



Below is 3 list of the properties that a parameter can have* 

All parameters need a TRANS* If the value of the parameter is ever 
reouested of the user? it needs a PROMPT and EXPECTr and if applicabler 



LAE<DATA* Numeric parameters should have a CHECK propertyj^ and possibly s 

DEFhAULT* 

TRANS - how to translate the parameter* The TRANS is list? i. f it contains 
the atom '^r the latter will be filled with the translation of the 
c o n t e jc t to which t i s p a t' ^ in e? t e r b e 1 o r*i ( e * ♦ ( 1 c i d e i » t i t y o f 

t))* Special verbs* such as "is"y "has* (all those on 
the list TRANGOERBS)r as well as the word "not" should be present 
35 lower-case litG?ral atoms f'or correct t rans 1 at i on oT the 
ne^Ration when the parameter is used in rules* 

PROMPT - how to ask for the parameter's value? no PROMPT meatis that it 

m a k. e s n o s g? ri s e t o a s k t li e < j s e r for t he value* T i '1 e I-’ i \ 0 i i F’ f a list* 
w h e ri the Question i s a s k o d • t h e i rt t lie list i s r e p . 1 c e d by 
the translation of the contort bein^J asked about? for 
multivalued parameters which are not "AGKALL'f the atom "(valu)‘ 
is replaced by the particular value bein.d asked about* 

EXPECT - the set of leSal answers to Questions askind about this parameter* 
A null EXPECT is implicitly (YES NO)* 

The most commort form of the EXPECT propei'ty is a list of 
the values (atoms)* If an elemG?nt of the EXPECT list is itself a 
list rather than an atomr it will be a list of one element and 
that c-?lement is to be evaluateri to proriuce a list of values* 

Usually the code to be evaluated will be the name of a list* This 
is useful when morG^ than onc^ parameter ivill have the same list of 
possible values* The code? to be evaluated* howc^ver'y may be 
arbitrary Lisp code which producers a list* This will b(.? useful if 
the list of ledal values depends on some pre^vious answer^ e*d*r 
in MYCINr valid answers for COLLECT (methiod of collectirid a 
culturG^ specimen) depends on SITE? thG? form evaluated may 
reference CNTXT - the obJcK.'t for which you are askind? and PARM - 
the parameter* 

A few atomic EXPECT" are recoSnicedt 
ANY - no restriction of the value 
NUMB - the value must be a number 

POSNUMB - the val'je iTiust be 3 positive number 
DATE - the vajlue? is a d<3te 



LABDATA - To you find out the value of this par<3mcterr first try jskind 
the user* The ori.sinal me?anins was that the parametc-M' 
was the result of a auan 1 1 ta t j vc? lab test? this ^13s bev^ri sene ral iced 
to be anything that the user is likely to kriG>w* If the:e user does not 
dive a d»a finite answer to tiui Quc'stionr the system will use rules (if 
any e?(ist) to deduce t^ 1 e value* For parameters that have no 
LABDATA propertyr the system first tries to conclude the? value usind 
rules* and only asks if no value was concluded (and a PROMPT exists)* 



115 



DEFAULT - if a numeric-valued parameterf the default units* This allows 
the user to sive the answer in a different unit? and the sustein 
will convert it to the default units. The rules assume (,hat 
the value is Siven in the default units. 

CHECK - A form to EUAL to' make sure that the user's numeric response is 
"reasonable*. The CKECK property has the form.* 

(CHECK UALU lower-bound upper-bound text confirm inte.^er) 
VALU will be bound to the user's numeric response to the Question r 
you must supply the lower «3nd upper bound. Text will be printed 
if UALU is not within the indicated rans'e. Confirm can be f or 
NILJ if Tr the user may confirm that the answer is correct ^ 
if NILf an answer outside the ranSe is always a mistal'o» [nte^^^er 
may be T or NIL? if T? the answer must be an integer. 

MULTIVALUED - the parameter is multivalued. This means that it can have 

several different correct values at the same time. ( E . i-i . » ALLERGIC 
the patient may be allersic to more than oiie druS.) This is 
different form the normal case in which the parameter i.s assumed to 
have 3 siri53le correct valuer and different values that are concluded 

represent competing hypotheses as to the true value. 

If the value of the MULTIVALUED property is T a separate 
Question will be asked for each value ( e . .s . y "Is the pati.ent 
allerdic to penicillin?*). If the value is the atom ASKALL.- 
one Question will be asked in which th j user is expected to ‘:5ive 
all the values ( e ♦ =J . r "Please list <all the antibiotice to wincii the 
patient is al lerfiic . * ) . 

The TRANS of a multivalued parameter is stated in the plural 
( e . ^ ♦ y ( the d ruds to wh i ch t is a 1 1 e r y i c ) ) ♦ This ph r as i ns i s 
necessary for proper translation throui^hout the system. 



PROPERNOUN - if the value s^lauld be capitalized in translation 

(e.fi.y NAME)r then the parameter should have PROPERNOUN property T. 

LEGAL VALS - Always the list of all le.dal values for this pormr b'jt is 
omitted if redundant (which it is for most parameters). All 
multivalued parms have a LEGALVALS property. In addition those 
parameters with EXPECTS which are pieces of code also have one. 

When a parameter has no LEGALVALS y the lesial values are assumed 

to be specified by the paramcte r ' s EXPECT property. A 

parameter with no EXPECT or LEGALVALS will be treated 

as 3 yes/no pa rainetti' r ? this affects its translation in many 

parts of the system. The LEGALVALS property may be of the :>3me forms 

as an EXPECT pi'operty. Two atomic forms are recognized. fb.*? atom 

CNTXT indicates that this parameter takes other contexts as its value 

(e.a.y in MYCINy the TREATFOR property of the patient is (-.he 

list of all the organisms in the-^ context tree tliat should lu? 

treated). The .atom TEXT means that the parameter takes arbitrary 

Pieces or text as its value. This will probably be the case for 

some -Soal parameter - the text will he the system's final analysis 

or recommendat los ♦ 
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CNTXTVAL - To be used when the LEGALVAL5 is the atom CNTXT ♦ TJie value 
of this nroj^erty is 3 list of PROP-VALs (context type.;) 
indicatiri£i tha t contexts of the specified type(s) can be 
values of this parameter* The value mas also be a fuitu't Lon of a 
context <?)♦ 



SPECIAL - indicates ambiguous answers to the PROMPT * Usually of form 
C ( <siTibiduou5 response.’:-- -Creo^jest for clar if icotion.>) *♦*) 

May also be triples witli 3rd element a default value-' i.n case user 
responds UNKNOWN* 

XTRASPECIAL - indicates a response? to a auestion that actuallv’ j.nc.I.‘jdes 

the values for more than one parametefrr is usua.»lly a I :u:; t of lists 
( ( res p o n s e 1 pan n 1 v a 1 u e 1 •:! p a r n 1 2 v a 1 u e 2 e t c * ) ( •=:. t' e ^ - x. : « : i. 2 . • etc*) 

iTt e a r*i 1 n .d t hat the re s p o ri s e dive n 'S h o ».j 1 d b e 1 j s e <:i to c c' 1 1 •: I. u >.;i i.? t • . o 
values for t e para in e 1 0 r s ^ m a '•/ a 1 s n b e ( ( -f i' e p o i i s e 1 . ( "•.> e '• * ♦ . ) 

me an in. d that t^le co^le should be executed when the re^X'oriSt. 
ti a s b e €? n s i v e n f s o nri e entries a r e o f t h e f o v iri ( •< c o d e • ; ■ :> ru .1 a r m 2 ) 

meaning 1 a t 1 f t h n c a d e E M A L s w i 1 1 ^ 1 1 ^ e .d i v e r 1 t' e s p o n . i..- •• K 1 1 r. > 1 .1 n e w 

V a 1 LI e w i 1 ]. be 1 j“i d i c a t e d — t h e ri e w v a .}. u e i s t e v 3 1 u e l ' ... ^ iii 1 3 1 '} d 

the user^s response? is the value for parm.2 ( 0 ♦ d » yes.'t i'; p I'cmeters 
when an answer other than yes or no is diven) 

REPROMPT - more specific than oridinal prompt? is printed out i^jhen the user 
enters “?’ in response to ttie oi.dinal prompt* 



117 



APPENDIX E 

EMYCIN/DECAIDS PREDICATE FUNCTIONS 

Non-Numeric Predicates 



In all the predicates that use VALU? yALU may be omit.te.j for 
yes/no paramters. If presentr VALU may bo an atom? a simple ILsI,.- or a 
list of V3lufc»-cf pairs* The predicates SAME and TMOUGHTNOT return numbers 
which will be mini mi zed by ^AND to determining^ the setting of T.-)LLY* The 
other predicates return true (or 1000) or false (NIL)* 

DEFINITECCNTXTfPARMD 

Returns true if FARM of CNTXT is known with certainty (cf - IvO? for 
yes/no parameters r also cf = -1»0>* 

Ex: (DEFINITE CNTXT IDENT) 

The identity of the? o r <1 n i s m .1 s k ri c w n w i t h c e r t a i i~i t y 

DEFISCCNTXT • FARM y OALIJI 

Returns true if FARM of CNTXT is known with certainty to lu* '/‘Al U 
(cf = 1*0)* 

Ex: (DEFIB CNTXT IDENT MYCGDACTERIUM- ID ) 

It is definite t a t the 1 d e n 1 1 t a f t h e or d a ri i s iti i s M y i; c t r 1 u i u - t b 

DEFNOTCCNTXT y FARM y VALU.l 

Returns true if FARM of CNTXT is definitely not VALU (cf ' I. . 0 • * 

Ex: (DEFNGT CNTXT IDENT VIRUS) 

It is definite that the identity of the or5L^anism is not Vj. ruo 
KNOUNCCNTXTyFARMH 

Returns true if the value of FARM of CNTXT is known (cf . ^ for 

yes/no parametersy also cf < -*2). 

Ex: (KNOWN CNTXT IDENT) 

The identity of the orsMnism is known 

MIGHTBECCNTXT r FARM y VALU3 

True if P A f \ M of C N T X T in .i. fi t be VALU* i ♦ e ♦ t ere i s ri o v :i. d i- 1 c e a 5.: a i r. s t 
it (cf > -*2) * 

Ex: (MIGHTDE CNTXT ADEQUArE) 

There is no evidence that the dose of the drud was not j- nropriate 
NOTDEFINITECCNTXTfFARMB 

Returns true if FARM of CNTXT is not known with certainty ( c f 1*0? 
for yes/no pa ramete rs y -1*0 < cf < 1*0)* 

Ex: (NOTDEFINITE CNTXT GENUS) 

The senijs of the organism is not known with certainty 



NOTDEFISCCNTXT y FARM y VALUl 

Returns true if FARM of CNTXT is thoijslht to be VALLJy but iiul. i h 
certainty (*2 < cf < 1*0)* 

Ex: (NOTDEFIB CNTXT IDENT CR YPTGCOCCUS ) 

It IS s ij s p G c t e d t hat t h e 1 d e n t i t y of t li e o r y a n i s m is c t } (. o c o c c u s 



NOTDEFNOTCCNTXT y FARM y VALU 1 

Returns true if FARM of CNTXT is thought not to be VALUy but not with 
certainty (-1*0 < cf < -.2)* 
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Ek: (NOTDEFNOT CNTXT IDENT E.COLI) 

It is suspected th£)t the identity of the ori^anism is not E*coli 
NOTKNOUNCCNTXT , PARh.l 

Returns true if FARM of CNTXT is not known (cf <- *2? for yes/no 
P3 raiTieters f - * 2 <= cf <= »2)* 

E>t: (NOTKNOWN CNTXT -IDENT) 

The identity of the or^fanism is not known 

NOTSAMECCNTXT f FARM t MALU3 

The lodical compliment of SAMEy returns true if FARM of CNTXT is not 
thought to be VALU (cf <- *2)» 

Ext (NOTSAME CNTXT SPEC3TAIN) 

Organisms were not seen on the stairrof the culture 

ONCEKNOUNCCNTXT f FARM . RETFLG.l 

Finds the value of FARM of CNTXT. If RETFLG is MIL? it means “you have 
found a value for FARM of CNTXT returns the same as KNOWN wou > If 

RETFLG is Tr it means 'find out all ynij c<an about FARM of CNTXT'’- tins 
causes traciniiii? but QNCEKNOUIN will return true even if nothiriil was found 
"'Lemycin.doc 85 



out* Intended to be invoked last amon.s the updated-by rules of FARM* 
Ext (ONCEKNOUN CNTXT SAMEBUG) 

There is an or dan isms with possibly the same identity as this 
or dsn ism 



GNCEKNOUN)^^ rCNTXT f FARMS! 

Traces FARMS of CNTXT and returns T redardless of the result of this 
tracind* This is like callind ONCEKNOUN repeatedlyy once for each parameter 

in FARMS? with RETFLG set to T in the calls* 

Ext (ONCEKNOWNic CNTXT (QUOTE (CURTHER FRIORTHER))) 

Information has been dathered about current druds of the patient 
and prior druds of thf? patient 

SAMEITCNTXT ? FARM ? UALU 1 

Checks to see if FARM of CNTXT is UALU returnind the associated cf ♦ 

Always returns a number? in a rule? t>AND will consider the clause *true“ 
if this number d reate r than *2. 

Ex: (SAME CNTXT SITE BLOOD) 

The site of the culture is blood 

THOLiGHTNOTCCNTXT ? FARM ? UALU! 

Checks to see if FARM of CNTXT is not UALU? i*e*? there is evidence 
adainst it* Always returns a nuuiber? in a rule? $AND will consider the 
clause “true" if this numher drocjter than .2* The number that is ret'jrnef 
is the nedative of the cf associated with the triple (CNTXT FAIiM UALU)? 
so the clause will be true if the cf associated with that triple is less 
than -*2* This is the al-debraic nedaticn of SAME? wliereas NOTSAME is 
the lodical nedation. 

Ex: (THOUGMTNOT CNTXT IDENT E*COLI) 

There is evidence that the identity of the orsianism is not E.coli 
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UNOTKNOUNCCNTXT f FARM r VALU J 

Returns true if it is not known whether the value of FARM of CNTXT is 
(or is not) UALU (-*2 <= cf <- *2)» 

Ext (^NOTKNOUN CNTXT IDFINT ET.COLI) 

It is not known whether the identltv^ of the ordanisiTi . 1 . s E*coli 



Nume r i c p red i cs te f unct i ons 



There are five numeric predicate functions to be used with y-arameter 
which take numbers or dates as their values* A parameter with DATE for it 
EXFECT propert'j accents a date as input y but internally stores ^he 
answer as the number of days ado (or since the time of the . i -.nrial 
consultation for stared cases)* The Lisp functions PLlJoy Dirt'-AiRCi'ICR . 

MINUS y TIMESf FQUOTIENT y and EXFT have t rans 1 at i ons in case l.hcu are used 
within these numeric predicates. Tho.? translations of numeri. c'cpt ess ions 
can be very wordy* To have an eKpression translated tersely <^us.i.n5i 
a r i t h m e t i c o p e r a t o r s y rri b o 1 ?> i i"t s t e a d of t e x t > y e I'l c 1 o s e 1 1) e p i e s i. o n i n 
■3 call to the function TR8EXF. 

BETUEEN^^(CVALUyLLIMyULIM3 

True if LLIM <> UALU < ULIM 
E;j: (BETWEEN^ (VALl CNTXT AGE) 10 50) 

The ase of the patient is between 10 years c?nd 50 years 

GREATEQ^CXy Y1 

True if X and Y are numbers and X >= Y* 

Ext (GREATEQ^ (VALl CNTXT NUMPG5) 2) 

The number of cultures from this!' site which were positive for this 
organism is Greater than or eaual to 2 



GREATERF1:CXy Y3 

True if X and Y are numbers and X > Y. 

Ext (GREATERFYv (UALl CNTXT CSFGLUC) GO) 

Tl)e csf £ilucose value is reate r than 80 



LESSEQ:|(CXy YD 

True if X and Y are numbers and X <- Y. 

Ex: (LESSEQ^ (UALl CNTXT CSFGLUC) 80) 

The csf s^lucose value is less than or enual to 80 



LESSF^CXy YD 

True if X and Y are nuiiibers and X < Y. 

Ext (LESSPY (UALl CNTXT CSFGLUC) GO) 

The csf slucose value is less tl>an In 80 
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Conclusion Functions 



The functions in a rule's ACTION concludes about one or more 
conte;rt-F'3 ramete T'-V3 1 ue triple* A cf for the triple is sped r i.ed in ths 
rule's ACTION* This cf will be modified by certaintu of i.he rule's 

PREMISE. $AND sets TALLY to the ce^rtointv of the PREMISE^^ defined to be 
the miniiTium of the values (nijinbers) returned bu eveluatinH the PREMISE 
clauses (onl^j SAME and TMOlfOHTNQT return numbers)* 

If 3 triple alreadv^ eKistsr this new cf is " combined " with the 
associated with that triple* Othei'wisey the new cf itself i.s 'ssociate 
with the new triple* 

CONCLUDECCNTXT r PARM r MALUE f TALLY r NUM 1 

Concludes that FARM of CNTXT i >3 MALUF. The conclusion made by this 

call will have a cf that is TALLY times NUM. 

E;<: (CONCLUDE CNTXT CONTAMINANT YES TALLY -)00) 

There is weaTlu suasestive evidence (.<?) that the orsarv! -m is a 
contam inant 

CONCLUDE:^(CCNTXT y FARM r TALLY ? VALS.l 

Performs multiple CONCLUDE 's for a sinj;U 0 CNTXT and PARM* UAI..US is a 

list of p 3 i r s ( V 3 1 ij e c f ) ? each value is c o i' i c 1 u d ed w i t h t h e c o t' t' e ; t ;■ d 1 n 

cf * 

Ex: CCONCLUDE<< CNTXT IDENT TALLY (QUOTE ((E*COLI 400) 

( KLEBSIELLA -PNEUMQN lAF ;?00 ) 

(PROTEUS- M I r;: a d i l i s o j 

There is evidence that tho? identity of the origan ism is t.-culi (*4) 
klebs iel 1 3-pneumoni ae (.3) p roteus-mi rab i 1 i s (*o) 



CONCLUDETCCNTXT r SU ITCHNUM r CASE r TALLY y PARM • UALU5 1 

Tabular rule concluding fn* Cor>cludes that PAR'M of CNTXT is one or 
more of the values in VALUSr accordin.d to the value of SUITCHNUh, 

SUITCHNUM is a form to evaluate which must return a nuniberv Tt is 
Generally a call to UALl for soiiie numeric parameter* 

UALUS is 3 list (MALI UAL2 **♦ UALn) of val'jes for PARM* 

CASE is 3 list of cases which test SUITCHNUM and supply cfs for 
the values in UALUS that is to be concluded* Possible cases curreritly areJ 
(LT NUM CFl CF2 *♦♦ CFn) if SUITCHNUM < NUM y conclude tha PARM is 
UALi with cf CFiy 

(BT NUMl NUM2 CFl CF2 *** CFn) if NUMl O SUITCHNUM < NUM2 • conclude 



that PARM is UALi with cf CFiy 

(GE NUM CFl CF2 *** CFn) if NUM SUITCHNUMy conclude that PARM 
is UALi with cf CFir 

(U CFl CF2 *** CFn) if SUITCHNUM = NIL* conclude that PAf-:M is 
UALi with cf CFi * 

Each CFi must be included in each case? if a particular value doc.'sn't 
applyy the corrc?spondind cf can be 0* 

Ex: (CONCLUDET CNTXT (UALl CNTXT LENSIGN) 

(QUOTE ((BT 9 13 -400 -500) 

(BT 13 20 -300 -400) 

(GE 20 (fOO 300) ) ) 

TALLY TYPE (QUOTE (BACTERIAL MIRAL))) 

The tvjpe of the infection is as follows: 

If the duration of tl)C ne^ijrolniii ca 1 sirtris is: 

a) between 9 days and 13 davr^ then: not bacterial (*4)* r*ot viral (*3)? 

b) betwiy?n 13 days and 20 days th(?n: not bacterial (*5)r ijot virsil (.4)* 

c ) . 5 ireator or eoual to 20 flaws theri : bacterial (*6)r viral (*i)? 
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CONCLUDETEXT CCNTXT f FARM . VALUE r TALLY . NUM 1 

This function calls CONCLUDE Tor pa ramete rs whose values are arbiti'ary 
peices of Le^t* It is a different function because it translates 
di fferentlu* 



DO-ALLCX: NL^ 

For multiple conclusions - evaluates each of its arguments (rule 
conclusions ) ♦ 

Ex: (DO-ALL (CONCLUDE CNTXT IDENT LISTERIA TALLY 500) 

(CONCLUDE CNTXT GENUS COR'YNEDACTERIUM TALLY 500) 

1) There is sud^3estive evidence (.5) that the identity of the 

orsianism is Listeria/ and 

2) There is sussestive evidence (.5) that the iJenus of the 

or53anistTi is Co rynebac te r ium 



DONTASKTCNTXTfPARM.1 

Conclusion function which says that PAR'H of CNTXT should not be asked 
(although it may be traced? if needed). 



Ex: (DONTASK CNTXT CONFORM) 

Dordt ask about the sirowth conf o rmat ion of the organism 



NOTRELEVANT'’CNTXT ? FARMS r CFl 

A conclusion function that indicates tl^at the value of each of the 
parameters in PARMs is not relevant for CNTXT: we shouldn't ever ask or 

try rijles to deduce the value. 

Ex: (NOTRELEVANT CNTXT (QUOTE (SECONDARY)) 1000) 

It is definite (1.0) that the following is irrelevant: the 
infection to which the bacteremia is secondary 

PRINTCONCLUSIONSCCNTXT/PARMdHFADERM 

Displays nicely the value of FARM of CNTXT? or indicates tliat no 
conclusions were made. Intended as a simple r^oal rule ACTION. If HEADER 
is Tf prefixes values with a simple heado:^r announc inS what these are the 
values of? if other non-NIL value? HEADER is printed? otherwise no header 
at all is printed? «ind noth i rid is men ti cried if there are no values. 

Special facility for use wi tli TEXT-valued potmtis: if FARM h<3S a 

property LAPEL . ORDER ? then TEXT values of eeual cf will be sorted by their 
labels. For LAPEL . ORDER-T ? the labels are integers? and the values will 
be sorted in ascendind order of label? otherwise the LAE<EL ♦ ORDER property 
is a list of labels (atoms)? an^.l the valijes are sorted according to the 
order of the labels in this list. 

Ex: (PRINTCONCLUSIONS CNTXT REGIMEN) 

Display the ther3?peutic r(. 3 dimen of the patient 

Auxi 1 1 i a ry f unc t ions 



$ANDCtt.CLAU5E51 NL 

Evaluates each of the predicates in $$CLAUGES until one fails? if all 
succeed (i.e. return T or «) cf ’> .2) the minimum cf is returned? else NIL. 
All rule premises and the predicates of all mappind functions must be 
calls to liAND - even if there is orily a sindle predic«ite clause inside 
th€? $AND. j 
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$ORi:$$CLAUGES: NL* 

Evaluates each of the predicates in $$CLAUSEGy returninfil the c*f. of the 
most hishlu confirmed claijser unless all fail* Stops if one of the clauses 
evaluates with certaintw (since the fTia;^ i mum 1*0 is ttie result). 

E:<1 <$0R (GREATERP'>J (MALI CNTXT UBC) 12.5) 

(GREATERP^K (MALI CNTXT PMNS) 80) 

(GREATERP^ (MALI CNTXT BANDS) 10)) 

1) The white count from the patient's peripheral CBC (in 

thousands) is .Greater than 12*5r or 

2) The percent of PMN ' s in tl>e CBC is Greater than 00? or 

3) The percent of peripheral WBC's which are immature in the CBC is 

sireater than 10 

LISTOFCND L* 

Simplu EMALs its argument (which is usu<ill':^ the name of a list). Used 
as 3rdum€-?nt to a basic Predicate wihen a choice of values is in>iicated. 

EkI (SAME CNTXT SITE (LISTCF STERILESITES ) ) 

The site of the culture is one of: those sites that are normal lu 

sterile 



ONEOFCX: NL^f: 

A no-spread auoteJ returns its ardument list* Used as a r^DjiTion t to a 
basic predicate when a choice of values is indicated. 

Ex: (SAME CNTXT SITE (ONEGF URINE SPUTUM)) 

The site of the culture is one of: urine sputum 

auoTECx: nl-k 

Lisp function* It is used in action functions that reouire a list of 
parameters? values? etc* (e.s*? CONCLUDET). 

textcn: L^ 

Constructs value of TEXT-valued pa rms. The first ardument is a label 
(or NIL) which mas be used to tad the value for snrtind by PRINTCONCLUSIONS . 
Tl^ie remainind ards are arbitrary rule forms to construct a te:rt phrase* 
Result is a list (TEXT label * Phrase)* If there is only one ard* the 
label is interpreted as a TEXT tad? i*e* (TEXT label) is the same as (TEXT 
label (TEXTAG label))* 



TEXTAGCTAG-1 NL 

Quotes a text "tad*? a place holder for a strind of text winch is the 
"value* of a conclusion parameter* TAG should be in PR'GP-TEXF? and should 
have a TRANS which is the strind in cjuestion (at least in current 
imp I ementat ioi i ) ♦ 



UNITSrUD NLt 

Returns its first ardument. The second ardument is not seen by the 
function? but is a unit and is used for translation. 

Ex: (GREATERP^ (MALI CNTXT AGE) (UNITS 3 YEARS)) 

The ade of the patient is d reate r than three years 

MALCCNTXTfPARMD 

Returns PARH of CNTXT as a list of pairs (value cf)? tracind the 
parameter first if it has not been traced yet. 
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VALl r ATM f FARM J NL 

Returns the value of F‘ARM of ATMr uithout its cf » Only sui table for 
5 in£lle-vslued parameters* ATM is evaluatedr F’ARM is not* 

UALYEWCCNTXTfPARMl 

Returns FARM of CNTXT as a list of pairs (value cf) in ordor of 
decreasing cf. This is the same as returned by OAL if the paf'airu^ler has 
already been traced. OALYEU causes- rm tracins? it can be interpr'eted as 
the system's current information about FARM of CNTXT 



Mapp'ind functions 



You r> T' o b a b I y w o ri ' t n o e d t o i..i s 0 map p i ri y f u i"i c 1 1 o ri s i ri :? r 1 - ; f' u t 

rules* The e)(ist to allow a rule to use p^a T'aincteM's of the cot 1 1-.-*. . 
to which the rule? is sppliedy as well as parameters of eacl’t of ■: specified 
list of conteicts. 

The functions map over a list $t>hAPSET which is usual Lv list of 
contexts. itf'REEVAR is the name of the iteration variable? it » “ 'lOt 
necessary to specify 3 value for ^1i1'>FREE'>'AR * the default FREII'.'fiF 1 be used 
if none is specified* T>$PRED is a j-redicate which has the saific ••'oriTi ;is 
3 rule PREMISF. Clauses in T>f>PRED mavj use CNTXT (the context wivu. n the 

rule is be ins applied) as well as FREE MAR iii their conteirt si -at 
If $'^MAPSET is a list of pairs (which it will be if the set . 1 . • tin.-.' r^i-sult 

of a call to (3ETALL or GETOFFSPRING ) ? the CARS fla.'^ should be s..t to T* 

T f) i s i n d i c a t e s t at e a c h 1 1 iti e 1> 'li F R F E M A R she u 1 d b e f-> ^ cf t o t li e C f 1 1 •' < > f f i 1 e 
current element rather than the element itself. ii<.)st of the f'ni«:ticfis 
return $ f> A NS ET set to their result. For funct.iorri whose result s 3 list? 
COLLECTEDLST is the default for $f>ANSET? for those that rv:;?tijMi u sin.sle 
element? t fi e d e f a 1 j 1 1 is F 0 U N D M A R ♦ T h o s e res u 1 t v a r 1 a b 1 e s a t' e ' ^ b »;.• 1 ^ t h i;? 
result of a m ap p in function in a n.ilc?'s PREMISE is often used in i.ihat 
rule's ACTION. 

A m a p p i n f u n c t i o i"i c a r 1 b e e jii b e d d i n 5J i ri a c a 1. 1. to t h e L. T. I"’ I ' ' j t j tie n 
NOT? and the action and t raris 1 at ions will be app ro: • r 1 a 1 1 vi I • ♦ 



FINDMAXClif MAPCET ? t>$PRED • TtTEST , TTFREEMAR ? ANSET ^ CARG 1 NL 

Mappirii-1 function tiiat retijrns VtANSET set to the element of i- lJMAP‘r>LT 
w fi i c h had t h e 1 a t' s e s t v a 1 u e o f $ t> f E G T out of all f . o s 0 el e iti r 1 1 s w h 1 1 ;: 1 1 
satisfied $iPRED. Global MAXMAL is set to this m a ; :i m u m valur- LtrEGT* 

Ex: . (FINDMAX (GETALL CURTHER ) 

($AND (KNOWN r>FREiiriRi jG UiIFNGTART)) 

(MALI 1->FREEDRUG WHENSTART) 
tFREEDRUC NIL T) 

You have examined the currcM'it druss of tfie p<)tient for i.'hi.cl> the 
, time since therapi^ wii,h tln.s dru.s was started 1 -s 1-nown? 

and have selected the* orie fiavin.d the in«-)ximufn value fur the 
time since tluarapy wj. th tfiis dmu was> started 
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FINDMINC $$MAPSET f $$PRED f $t>TEST f $$FREEUAR , $$ANSET r CARS 3 NL 

Like FINDMAXf but looks for the the smallest value of $$TEST f and sets 
Global hINVAL* 

Ek: (FINDihIN (GETALL PRIORTHER) 

($AND (LESSEQ^ (VALl t>FREEDRUG WHENSTOP) 5)) 

(VALi $FREEDRLJG UHENSTCiP) 

$FREEDRUG NIL T 

You have examined the prior dru^s of the patient for which the 

time since therapu with this druri was discontinued is less 
than or eaual to 5 dassf and have selected the one havin<^ 
the minimum value for the time since therapy with this 
drud was discontinued 

FORALL C $$MAPSET f $$PREri y $$FREEVAR r CAR33 NL 

True if $t»PRED is true for each element of t>$MAPSET ♦ Function returns 
(trivially) true if map set is empty* 

Ex: (FORALL (GETALL PDSCUL) ($ANi:i (NOTSAHE FREEMAR GPECSTAIN) 

(NOTSAME FREEMAR CR YPTn-SFRnLGG Y ) 
(NOTSAME FREEUAP CGCC I-GFPnUJGY > ) ) 

For each of the the positive cultures of the patient it is true that 

1) Organisms were not seen on the stain of this culLurer 

2) The cruptococcal antirien in the csf was not positivcf and 

3) The^ csf coccidioides serolo^iy was not positive 



THEREAREC$$MAPSET r t»$PREP f $$FREEUAR * $$ANSET r CARS . DUPLES3 NL 

Collects all the elements of t1>MAPSET for which $$PRED is true* 

If DUPLES is Tf it returns a list of duples pairin.vi each element 
of $$MAPSET that succeeded with the value (number) returne^d wiien 
the predicate? was appliedto that element* 

Ex: (THEREARE (GETALL KNOUNORG) 

($AND (DEFINITE CNTXI IDENT)) 

NIL COLLECTEDORGS D 

You have examined the organisms isolated from positive crjltures 
obtained from the patientf selecting those for which the 
identity of the orsianism is known with certainty 

THEREARE !CN3 L'M 

Re^turns true if LST is non-empty* This is like a call to THEREARE with 
$$MAPSET Tf but translates better* 

Ex: (THEREARE! ( GETOFFSPR I NG CNTXT SMEARGRG)) 

There are organisms noted on smears of this culture 



THEREXISTSCTThAPSET r $$PREIi f $$FREEVAR r $$ANSET . CARS 1 NL 

Like THEFvEAREf but Just finds the FIRST element (or CAR of element) 
satisfyins $$PREDr and returns that* 

Ex: (THEREXISTS (GETALL CURTHER) 



You 



($AND (SAME ■ FREEVAR DNAME (GNEOF AMPICILLIN CARDEN I C ILL IN 

PENICILLIN METH.TCILLIN) ) ) 

NIL NIL T) 

have examined current di'uSs of the patieritf and have^found one 

for whit?h the n< 3 me of t^lis druid is one of: ampicillin 
carbon i c i 1 1 i n pen i c i 1 1 i n me U) i c i 1 1 i n 
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FunctionG used within hsppin^ Functions 



GETALLCCTYPED NL 

Rci^turns a list of all corrteKts of type CTYPE* Currentls lit the foriu 
<(cntxt 1000)* ♦»)y until we dot around to beind neater* This is often used 
in the $$MAPSET slot* 

GET0FF5PRTNGCCNTXT y TYPE3 

Returns a list of contexts of type TYPE descendant to CNTYf. Currently ^ 
list (<cntxt 1000) **.)* 

APPENDCL3 Lt 

Lisp function* It is used in the $$HAPSET slot when fiiore tii.-n one 
type of context is to be examined* 

NOTSAHEANSCCNTXTl yCNTXT2rPARh: 

Premise clause which is true if CNTXTl and CNTXT2 have d i. f f e ren L values 
SAMEANSCCNTXTl rCNTXT2/PARiMn 

A premise function that is true? if CNTXTl and CNTXT2 have f.he same value 
for parameter PARH* 

TRACEDPCCNTXT y PARhl 

True if PARM has been traced for CNTXT * This is used when thi? 
value of a parameter of one context is to be transfered to ario^her context* 

To avoid circular reasoninsly we specify that the tartlet pa ramc (. •; r must 

already be traced for a context to satisfy the predicate* 

Ex: (THEREXISTS (APPEND (GETALL POSCUL ) (GETALL PENDCUD) 

($AND (TRACEDP FREEOAR NGGOCGMIAL) 

(KNGWN FREEVAR NOSOCDhIAL) 

(SAMEANS CNTXT FREEOAR SITE)) 

NIL FOUNDCUL T) 

You have e)<air.ined positive cultures obtained from the patio??nt and 

pendinS cultures of the patient/ and have found '.one for whic.h 

1) All information about whether the infection was 

acQuired while tt)e patient was hosp i ta 1 i. zed has 
been sat he red/ and 

2) It is known whether the infection was acouiT'od while 

the patient was hospital irf?d^ and 

3) The culture under cons i 'de rat i on and this cul. ti.ire have the 

same value for the site of the culture* 

Action Functions used in Rules with Mapping Functions 



C0NCLI5TCCNTXT fPARMy GVALy TALLY3 

GVAL Is a list of duplos • ( va lue cf)» Concludes that PARM of CNTXT is 
each of those values/ modified by TALLY* 

Ex: (CONCLIST CNTXT IDENT GRIDUAL 900) 

There is strongly su«i.Sest i vf? evidence <*9) that each of (Jx? ones 
that you found is the identity of the OT'dani‘>m 

CONCLUDEALL CCNTXTS / PARM / OALU ^ CF3 

Makers the same cone 1 «.is i on for eacii of a list of conte;tts* 

Ex: (CONCLUDEALL CDLLECTEDCULS REQTHER YES -1000) 

It is definite (1*0) that the nrsanisms isolated from the cultures 
that you selected should not be considered foT' therapy 
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TRANSDIFPARhCFROM » rFRARM^TG! r TPARM f CF r POSITI^EG 

Tr3n?r>fers the value of FPARH of FROM! to TFARM of TO ! f iriodified bu CF* 
Either FROM! or TO! mau be a list of contej:ts or a sin<3le context* FPARM 
and TPARM are different parameters* If POGITIOE is setf it onlu transfers 
values with non-nedative CFs* 

Ex: (TRANSDIFPARM CDLLECTEDORGS IDENT CNTXT COVERFOR 700) 

There is sui^destive evidence (*7) that the identity of each of the 
ordanisms that you. selected is the ordanisms (otl>er than 
those seen on cultures or smears) which midht be causind 
the infection 

TRANSLISTCFROMf TOrPARMSr 13 

Transfers to context TO the values of of each of the FARMS of the 
contexts in FROM* modifuind the cf's by I* 

Ex: (TRANSLIST (VALYEW CNTXT SAMFBUG) CNTXT (QUOTE (IDENT)) 1000) 

It is definite (1*0) that these proPG^rties - ident - should be 
transferred from the orsianisms with possibly the same 
identity as this ordanism to this ordanism 

TRANSPARMUFROM I *T0! ^PARMyCFl 

Transfers the value of FARM of FROM! to TO ! r modified bu CF» Either 
FROM! or TO! may be a list of contexts or a sinsle context* If POSITIVE 
is setf only transfers values with non-nedat i ve CFs* 

Ex: (TRANSPARM FOUNDCUL CNTXT SECONDARY 1000) 

It is definite (1*0) that thv? information that you have dathered 
about the infcection to which the bacteremia is secondary 
is also relevant to this culture 
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APPENDIX F 

DECAIDS USER'S PROCEDURES 



In order to present the procedures necessary to use the 
DECAIDS prototype decision support program, the following quick- 
reference material is provided. All TOPS- 20 and EMYCIN/ 

DECAIDS commands must be followed by a carriage return to 
enter the user command or response. A sample consultation 
is presented in Appendix C. 

1. Select the desired ARPANET compatible terminal to 
be used. 

2. Connect to the local ARPANET TIP. 

3. If using dial-up device, upon receiving the carrier 
tone, connect the telephone to the terminal's modem. 

4. Depress the "RETURN" key once. 

5. The following will be printed by the system: 

NPS TIP 420#: 2 

6. The user next enters 

@1 116 

This will connect the user to the University of Southern 
California's Information Sciences Institute System E computer 
referred to as ISIE. 

7. The system will respond xvith: 

TRYING . . . 

OPEN 

ISI-SYSTEM-E. TOPS-20 MONITOR 3A(105) 



1 
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The symbol is the TOPS- 20 operating system's prompt. 

After this symbol, a user may enter his commands or responses. 

8. The user next enters: 

LOG DECAIDS escape 

9. On the same line with the last entry, the user 
will be challenged with: 

(PASSWORD) 

10. The user must respond to (PASSWORD) with: 

"PASSWORD" escape . 

(The actual password may be obtained from LTCOL R. J. Roland 
or Professor Gary Poock.) 

11. Again on the same line as above, the user will be 
challenged with: 

(ACCOUNT) 

12. The user's proper response to (ACCOUNT) is to enter 
a carriage return. 

13. The current TOPS- 20 operating system will respond with 
accounting data, date, and user file information. This infor- 
mation may be viewed or terminated with: 

Control 0 

14. At the end of the login information the prompt 
will be returned by the TOPS- 20 operating system. At any 
time after logging in has been completed, the user may enter 
a : 

Control C 

in order to return to an prompt and thereby facilitate a 
quick log-off with the command: 
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LOGO 



15. To enter the EMYCIN/DECAIDS system, the user must 
type : 

EMYCIN.EXE 

16. The EMYCIN.EXE will respond with; 

LOADING CHANGES . . . 

FILE CREATED (date) and (time) 

CHANGES COM3 

(<DECAIDS> CHANGES .. current number) 

(<DECAIDS> EMYCIN.EXE.8. <DECAIDS>LISP.EXE.80516) 

17. The is the EMYCIN prompt symbol after which 

DECAIDS commands may be issued. 

18. To begin the DECAIDS consultation program, the user 
enters : 

BEGIN] 

The right square bracket must be entered. A short delay 
(10 to 30 seconds) may be experienced before the next system 
response occurs. 

19. The user will next be challenged with; 

SPECIAL OPTIONS (TYPE ? for HELP) 

20. The user may respond with a carriage return if no 
special options, such as fault tracing (i.e., FT 1 or 2 or 
3 or 4) , are desired or with a "?” if an explanation of 
available options is desired. 

21. The system will next challenge the user with; 

INSTRUCTIONS (Y or N) 

22. On the same line a "Y" response to 21 above will 
present a line of instructions on the use of the DECAIDS 
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system and an "N” will continue with the DECAIDS consultation 



session . 

23. DECAIDS will continue with the consultation by 
presenting the user with; 

(current date) and (current time) 
0RGANIZATI0N=1 



1) THIS PROGRAM IS DESIGNED TO PROVIDE 
MANAGERS AT ALL LEVELS WITH ADVICE 
CONCERNING THE USE OF THEIR COMPUTER 
RESOURCES. IN ORDER TO PROVIDE THIS 
INFORMATION, THE USER WILL BE ASKED TO 
FURNISH DATA CONCERNING: HIS ORGANI- 

ZATION, ITS LEVEL OF TRAINING, THE 
ORGANIZATION"S LEADER, THE ENVIRON- 
MENT AFFECTING THE DECISION, AND THE 
TASK FACING THE ORGANIZATION. TOAT 
IS THE TYPE OF PROBLEM WHICH THE 
ORGANIZATION FACES? 

This is the beginning of the consultation session. This first 
question about the type of problem may be answered with any 
subject name, for example: electronic warfare. A full 

consultation session is presented in Appendix C. 

24. The consultation will continue by asking ten 
additional questions for the user to answer at the end of 
which the user will be presented with the DECAIDS recommen- 
dations . 

25. After the recommendations are offered, the system 
will ask: 



Do you wish advice on another patient? 

(Based originally on a medical background, the inference 
engine continues to ask for "patients.") 
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26. A user response of "Y” will start another consulta- 
tion session with a title of ORGANIZATION- 2 and an ”N” 
response will return the user to the TOPS- 20 operation system 
and its prompt of: 

@ 

27. To log off the system from the TOPS- 20 operating 
system the user need only enter: 

LOGO carriage return 

28. The system will respond with: 

KILLED JOB (#), USER DECAIDS, ACCOUNT NPS-OTHER- 
STUDENTS, TTY 167, AT (date, USED (time) 

CLOSED 

and the session is closed. 
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APPENDIX G 



DECAIDS KNOWLEDGE BASE MODIFICATION PROCEDURES 

The following procedures are provided as a quick 
reference to fill in a new knowledge base or modify an 
existing one. The system designer will be required to declare 
parameters, define rules, and to save (make a file called 
CHANGES) the declarations and definitions. The parameters 
declared may be context names, rule group names, or value 
parameter names. The EMCYIN system prompts (requests for 
values from the designer) for the types of parameters 
mentioned above will be summarized in this section and 
examples will be provided. A carriage return is to be typed 
after each sample command. Entering the EMYCIN file is 
accomplished as described in Appendix F. 

A. DECLARING PARAMETERS 

1. To declare parameters the designer enters the 
following command after the EMYCIN prompt of " ” 

GETPARMS 

2. The system, will respond with: 

PARAMETER NAME: 

3. If the system designer then responds with the name 
of a new parameter, the system will commence prompting for 
parameter property values. 

4. The first prompt for a property value will be: 
PROPGROUP: 
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5. A response to PROPGROUP of 

a. ALLNAMES: signals the system that the parameter 

is to be a rulegroup name 

b. PROP-VAL signals that the parameter is to be a 
context name, and 

c. PROP- (name) signals that the parameter is to be a 
value parameter in the parameter grouping of (name) 
which is of the designer's choosing. 

6. RULE GROUP DECLARATIONS 

a. If the parameter is to be a rule group, then 
the next property prompt will be 

CONTEXT? 

b. The designer should respond with the context (s) 
names to which the rules of the named rule group 
will apply , i . e . : 

ORGANIZATION 

c. The next property prompt will be: 

SVAL: 

d. The designer shall respond with the appropriate 
context name, i.e.: 

ORGANIZATION 

e. The following prompt will be for: 

CTRANS: 

f. The appropriate context name is the correct 
designer response, i.e.: 

ORGANIZATION 
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g. The next prompt will be for: 

PROPTYPE : 

h. Here, the designer should respond with: 

PROP -ALLNAMES 

The system will return with a prompt for: 
SUBPROPERTY: 

A carriage return after "SUBPROPERTY” will 
return a system response of: 

PARAMETER NAME: 

A carriage return after "PARAMETER NAME" will take 
the user out of the GETPARMS subprogram and return 
a : 

DONE 

7. CONTEXT DECLARATIONS 

a. If the response to PROPGROUP is PROP-VAL, then the 
first prompt for a context parameter will be: 

TRANS : 

b. The designer response to "TRANS:" is the 
designer's literal interpretation of his intent 
for this context name, i.e. : 

(the organization) 

c. The next property prompt is: 

MAINPROPS: 

d. The designer response may be a carriage return if 
no MAINPROPS are to be used or a list of param- 
eter names , i.e.: 

(PROBTYPE TASK STRUCTURE TECHNOLOGY) 
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e. The context parameter's next property prompt will 
be : 

PROPTYPE : 

f. The designer should respond to PROPTYPE with the 
value parameter group (s) names to which this 
context will apply, i.e.: 

PROP-ORG 

g. The next property prompt will be: 

TYPE: 

h. The correct designer response to "TYPE:" is the 
appropriate context name, i.e.: 

ORGANIZATION 

i. The system will next prompt for a response to: 

RULETYPES : 

j. Here, the proper response is the rule group (s) 
names to which the context will apply, i.e.: 

(ORGRULES) 

k. The final property prompt seen in context declara- 
tions in DECAIDS is : 

GOALS : 

l. The designer should respond with those goal- 
parameters for the current context, i.e.: 

(DECAIDS FORMAL UNKSTRUC) 

m. After prompting for the standard property 
values listed above, the system will request: 

SUBPROPERTY: 
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n. If the designer has a need to use additional 
property values, such as LABDATA, then he should 
respond to ''SUBPROPERTY : ” with the name of that 
property which he should use, i.e.: 

LABDATA 

o. The system will then prompt the designer to pro- 
vide a value for the subproperty just defined, 

i , e . : 

LABDATA: 

p. A proper response to "LABDATA:" is: 

T 

q. When the designer has completed declaring param- 
eters, a carriage return should be entered to the 
systems request for another subproperty defini- 
tion . 

r. The system will next return with: 

PARAMETER NAME: 

A carriage return response here will cause a 
system response of: 

DONE 

and return the designer to the EMYCIN.EXE file 
with its prompt. 

8. SAVING FILES 

a. The above work is saved in a CHANGES file with the 
following command: 

MF CHANGES 
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b. The EMYCIN file will return the now current 
edition number of the CHANGES file. 

9. CHANGING A PROPERTY VALUE 

a. Changes to a property value are made by typing the 
property name while still in the GETPARMS sub- 
program, i . e . : 

PARAMETER NAME: STRESS 

SUBPROPERTY ; TRANS 

b. The system will return that subproperty to the 
designer expecting a new value to be entered, i.e. 

TRANS: 

c. The designer should enter a new value and a 
carriage return, i.e.: 

(THE NEW ORGANIZATION) carriage return 

d. The system will challenge with 

[NEW VALUE] 

e. On the same line as ''[NEW VALUE]," the designer 
must respond with: 

YES, for "YES" or N, for "NO" 

f. The system will then continue prompting with: 

SUBPROPERTY: 

B. DEFINING RULES 

1. Rules are defined by initiating a call to the 
GETRULES subprogram with: 

GETRULES] 

2. The system will respond with: 
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RULE#, NEW or SUBJECT FOR NEW RULE: 

3. To enter a new rule, the designer must respond with: 

NEW 

To edit an old rule, the designer must respond with the 
desired rule number to be edited. 

4. After "NEW" is typed by the designer, the system will 
respond with: 

ANTECEDENT RULE? 

5. In most cases the rule will not be an antecedent rule 
and the correct response is simply: 

N 

6. The system next sends: 

RULE (number) 

PREMISE: 

7. For a new rule, the designer should first define a 
rule premise and should respond to 6 above with his premise 
statement, in the INTERLISP syntax, i.e." 

($AND (SAME CNTXT STRESS LOW)) 

8. The systems response will be either: 

a. an error message for syntax or undeclared 

parameter , 

or 

b. RULE (number) 

ACTION: 

9. In response to the system's request for the ACTION 
statement, the designer should enter the rule's appropriate 
action statement, i.e.r 



139 



(CONCLUDE CNTXT SIZE LARGE TALLY 900) 

The "TALLY 900" is the designer's certainty factor entry. 

10. The system may again respond with an error message or 
return : 

SUBJECT OF RULE (number) IS (rule group name) 
[CONFIRM[ 

11. If (rule group) is the correct name to which the 
rule belongs, then enter 

Y 

immediately after [CONFIRM], i.e.: 

[CONFIRM] Y 

12. If in response to "RULE#, NEW or SUBJECT FOR NEW RULE:," 
the designer enters a rule number, the system will return: 

TRANSLATE, DELETE, NO CHANGE, OR NAME 
OF PROP TO MODIFY: 

13. The designer may now specify the premise or action 
statement if he chooses to edit either, i.e.: 

TRANSLATE, DELETE, NO CHANGE, OR NAME OR 
PROP TO MODIFY: PREMISE 

14. The system will respond with the current premise value 
and on the next line return: 

PREMISE: 

awaiting the new value. 

15. After the new value has been entered, the system 
will challenge with: 

[NEW VALUE] : 
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a ”Y" for "yes" or "N” for ''no” immediately after [NEW 
VALUE] is the correct response. 

16. A carriage return after RULE#, NEW or... will cause the 
system to return: 

DONE 

17. Rules may now be saved with: 

MF CHANGES 

18. Debugging of error messages may be facilitated by 
reference to the XEROX INTERLISP Manual and via communications 
with the AI personnel at Stanford University. (ARPANET 
address : 

SCOTT@@@SUMEX-AIM 

Carlisle Scott is a programmer with the AI group at Stanford 
University who has provided a great deal of assistance in 
learning the EMYCIN system.) 

C. PRINTING PARAMETERS AND RULES 

1. The parameters list is printed out with the follow- 
ing command: 

PRINTPARMS (NIL T 72 T) 

2. The rules may be listed with the following command: 

(PRINTRULES rulegroup name 'B) 

D. LOGGING OFF FROM THE DECAIDS FULE 

1. From the DECAIDS file a CONTROL- C command and no 
carriage return will return the system designer or consul- 
tation user to the TOPS- 20 operating system. 
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2. The command: 

LOGO 

will log the system user off of the computer at ISIE and off 
of the ARPANET TIP. 

3. The system will terminate with: 

KILLED JOB USER DECAIDS, ACCOUNT NPF- 
OTHER-STUDENTS, TTY 13S, at (date time), 

USED (time) CLOSED. 
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